Relative Paths

[nm123456789]

The use of true relative paths would greatly improve team collaboration of Labview projects for several reasons.

1. Not everyone uses the same exact path to their libraries, sub VIs, etc. It is extremely unproductive and annoying when you are working in a team environment and say a co-worker needs to check his sub VI with the main project, he gets it working, and then checks in his work. You check out the work, open in the main VI, and Labview asks where is XYZ.vi is and then you relink it. You need to complete this process every single time the project goes back and forth between the two workers. This is even more annoying when there are tons of VIs that need to get updated or there are several people on the project where work is split up into logical components.
2. Relative paths would allow for better use of version control systems. After checking out a local copy of VIs, say one folder is named Libraries and contains the sub folders Lib1 and Lib2 and another main folder is called Projects and you have Proj1 and Proj2. Who cares if the local repo copy is located on the C: drive or 😧 drive or buried deep somewhere on your computer. The file structure of your repository will be the same no matter where you put it. (You guys push version control at seminars – and I’m glad that you do – but it’s even harder to use without relative paths.)
3. Almost every single programming language's IDE, design tool, and even office suites support relative paths.
4. Even if you are a standalone team and say your computer dies but you have all of your work stored on a repository or backed up on a network drive. When you get your new computer up and running and place your files back on your computer but say a slightly different location, again you have to go back into your project and relink everything to the correct path.
5. Productivity would increase!
6. I’m sure there are several other examples but I’m hoping you get the idea.

Maybe relative paths would only be supported if you created a new Labview project and specified relative paths in that project. This seems the most logical place to put them.

Please please please add in support for relative paths. Thanks!

[wiebe@CARYA]

If you move parts of a code base, relative to other parts, you get conflicts.

This problem is not caused by absolute paths, relative paths (as are used at the moment) also have this problem.

It is a bit annoying that you need to point out that you want to use the VIs that LabVIEW can find, and that you don't want to use the VIs that LabVIEW cannot find. But the alternative, silent acceptance, could be dangerous... This is how it used to be (~LV7 IIRC). It changed for good reasons.

[jk010]

I think the case you describe of having different drive locations or root directories does explain a lot of the problems we've been having.  I don't exactly know how the volumes of the network storage are mapped, since some in the office have a drive letter assigned and some use the \\local UNC path.  When I drag a whole project from one folder to another on the network, to me it seems like the same root directory.

The whole concept of a vi "knowing" things like what project or library it "belongs" to is also new to me, coming from a C/C++ and Java background.  In the future I hope to stick to C# and Measurement Studio.  There are a lot of things that add up in Labview that just aren't for me.

[wiebe@CARYA]

>The whole concept of a vi "knowing" things like what project or library it "belongs" to is also new to me.

A VI knows it's library, that's true. AFAIK, a VI (nor a library) does not 'know', nor does it need to know, which project it belongs to.

>There are a lot of things that add up in Labview that just aren't for me.

Suit yourself. This is not the best place to bring that up though .

[AristosQueue (NI)]

In LabVIEW NXG, a VI does not store any paths to its pieces. The projects declare what code repositories (directories or online depots) are in scope and the subVIs of a VI resolve against that.