When does LabVIEW use Relative/Absolute path to find dependencies?

[Gregory]

This problem came about when committing code to source code control from one computer, and then getting a fresh copy of the code from another computer. Assume all of my code is housed in Project1 and Re-Use, which are located like this:

• C:\
  • LabVIEW
    • 2016
      • Re-Use
      • Projects
        • Project1

Now if we move Project1 (or check it out from SCC) to a different Location so that we have:

C:\

• LabVIEW
  • 2016
    • Re-Use
    • Project1

LabVIEW no longer looks for the Re-Use in C:\LabVIEW\2016\Re-Use, but C:\LabVIEW\Re-Use, which is obviously a result of moving Project1 up a level in the directory. I do include Readmes with the code to describe where to place it, but often those are Unreads. So I am curious, is there a way to make LabVIEW use absolute paths instead of relative? When using VIs from vi.lib or instr.lib it does not seem to care where the project is.

Thank you,

Gregory

[Gregory]

Just to clarify, I think it is good that it uses relative paths. Because though my working folder is C:\LabVIEW\2016, someone else's could be different and as long as they maintain the relationship:

• <Working Folder>
  
  • Re-Use
  • Projects
    • Project1

The project should find all dependencies. I'm just curious to know more about when LabVIEW uses relative or absolute paths.

[altenbach · Accepted solution]

"tools...options...paths...VI search paths" defines where it looks when not finding a dependency in the requested relative location.

[JÞB · Accepted solution]

It would be much better to have a "Come to the river" day and wash away all the sins of your developers that won't maintain rel paths in the dev environment.  However, you can work around it on a case by case basis.

Kind of a "I know a trick so it doesn't bother me when you do bad things" work around.

Add ...reuse\ to your search paths

[Gregory]

Ok great! I agree Jeff, I will continue to use relative paths. The other thing I have are some project templates which are located next to Projects like so:

• Projects
  • Project1
• Templates
  • Template1

So I think it should be fine if I put some Re-Use code into Template1, and then make a copy of Template1 located at Projects\Project2. But on the other hand, I kind of like my templates to not have Re-Use code in case I need to use them for a consulting job or something...

[JÞB]

---

@Gregory wrote:

Ok great! I agree Jeff, I will continue to use relative paths. The other thing I have are some project templates which are located next to Projects like so:

• Projects
  • Project1
• Templates
  • Template1

So I think it should be fine if I put some Re-Use code into Template1, and then make a copy of Template1 located at Projects\Project2. But on the other hand, I kind of like my templates to not have Re-Use code in case I need to use them for a consulting job or something...

---

Now you are getting into a subject I wish....... I had the Advanced users track pick up that subject from me a few years ago (Templates)  I just never got to NI Week to give it in my version.  As a synopsis.

What kind of "Template" do you mean?  

• Icon Templates belong in <User>\Documents\LabVIEW Data\Icon Templates\
• VI Templates belong in <LabVIEW>\templates\...  They should also go on your palattes under user as "Merge vis"? (renamed "Place vi Contents" way back) you loose base VI documentation and other properties that are maintained when creating the vi from template (File>> New... not New VI)
• Project Templates go in <LabVIEW>\ProjectTemplates\Source\  And, feel free to have those call re-use libraries as dependencies! (Treat Re-use.lib exactly like vi.lib or any TK)

[Gregory]

Ok, these are project templates, including build specs, launcher, splash screen, and QMH-style modules with some scripting tools, that I like to use as a jumping off point for new projects. I guess I could put it in the Project Templates Source, but I do not start a new project too too often, so copy and pasting seems just as convenient for me.

[JÞB]

---

@Gregory wrote:

Ok, these are project templates, including build specs, launcher, splash screen, and QMH-style modules with some scripting tools, that I like to use as a jumping off point for new projects. I guess I could put it in the Project Templates Source, but I do not start a new project too too often, so copy and pasting seems just as convenient for me.

---

Put them in Project Templates.  Add the documentation. Add the links to the existing Project Template Design guides.  You can then spend all the time you save yourself in the future and the time you save training the new-guys and the time you save in code reviews and debugging thanking yourself for being such an awesome CLA!  (Alternately you could keep on as before)

[James_W]

I have a very similar problem with some common libraries and I just can't get my head around whats going on.
Class 1 Folder \class1.lvclass
lib1 folder\folder\my.vi

if they are both opened in folder c:\my fol\... then checked into SCC and checked out to c:\my newfol\...
class.lvclass breaks my project by referencing my vi in the expected folder

c:\my newfol\Class 1 Folder\lib 1 folder\folder\my.vi

instead of 

c:\my newfol\lib 1 folder\folder\my.vi

What the 😬 is going on with the relative paths ..\..\ in class1 and why isn't it linking correctly?

Cheers
James

*edit - correct paths 1st input to correct them

[rolfk]

To answer the topic title:

When both the referrer and referee are on the same volume at the time the VI is saved, LabVIEW stores a relative path.

When they are on different volumes LabVIEW stores the absolute path.