VI Search Paths: include a RELATIVE path to the parent of topvi

[RedSoxFanatic]

Using the LabVIEW VI search paths, how does one include the RELATIVE path to the parent of the topvi?
What is the proper syntax? I tried DOS-like syntax but LabVIEW would not accept it.

[Ankita]

Hi,

You can use the Current VI Path function to get the complete path to the top level vi and then use a Strip function to get the path to the directory/folder in which the top vi resides if that is what you mean by the "parent" of the top VI.

I hope it helps.

Ankita A.

[RedSoxFanatic]

I have relative paths in my code, as you described, but I need for LabVIEW to search the parent directory of the topvi for subVIs during load. I realize I can BROWSE for a fixed path, but I need to use a relative path.

Any ideas?

Thanks!

[winterishere8]

How about using List Directory OR File/Directory info and using the pattern as *.vi ? Will that help ?

Sridhar.

[RedSoxFanatic]

I appreciate your response. However, in this case, the solution cannot be in the code. The same code must run under two very different directory structures.

Without modifying code, I believe the solution lies in the VI search path - and it must be a relative path.
Any other ideas?

[alkazaa]

Are you trying to customize LabVIEW's VI search strategy (this is the only place where the term 'VI search path' makes any meaning to me)

OR

are you trying to access files/directories programmatically??

IF the latter is the case, you should use the function 'Strip path'.

Example is shown below:

[RedSoxFanatic]

I am indeed trying to modify LabVIEW's VI search strategy:
Tools>Options>Paths>VI Search Path.

I need the SAME code to run in different directory structures: some subVIs do not reside in subdirectories of topvi, but in directories at the same level as topvi.

I have submitted this question to NI and they have not been able to come up with a solution yet.
Consider it a challenge!

[JeanPierre]

I don't think you can specify a relative path in the VI Search Paths list. However, I can't figure why you need to specify a search path because when a VI is saved, relative paths to its subVIs are stored so that they will be found the next time the VI is loaded, even if the directory structure has moved (no relative move of VIs).

If this is really a problem, load your VIs from a VI located in the top directory of the hierarchy.

[Dennis_Knutson]

Like Jean-Pierre, I can't really see the need for this. Can't you simply create a distribution llb with your main and subVIs in it?

[Mark.Barrett]

It's extraordinary to me that this is regarded as such a surprising thing to want to do; I'm in exactly the same situation, and am just as surprised there is apparently no solution. Here's the situation I find myself in:

I'm developing a piece of code in c:\blah\app\foo.vi;
I want to utilize a subVI at c:\blah\lib\bar.vi;
I have a co-worker who is also developing in this same basic directory structure, but her "blah" is different than mine.

My understanding was that the whole point of relative paths was so that I can go to Tools->Options->Paths and under VI Search Path add something like \..\* so that supporting subVIs under the \lib directory are automatically searched for, so that as my co-programmer and I hand this piece of code back and forth we don't have to go through the hassle of reassigning the path of bar.vi each time one of us saves this piece of code.

Now, I'm the first to admit I don't know a lot about the Shared Library option, but from the little work I've done with them I get the impression they're pretty static items; if I changed foo.vi or bar.vi above, my assumption is I'd have to re-create the library, that it wouldn't dynamically link to the files I was modifying, and I'd just as soon not have to re-create the .dll every time I modified either one of these files.

And I certainly understand there are a lot of kloodges to get around this current situation: my fellow programmer and myself could just make our blahs identical, or we could do everything under a subdirectory that's already being searched for library code, or any number of other things. But the thing is that if LabVIEW already has the concept of relative paths in place, as they clearly do with and and the rest, it should be a natural and easy thing to do to look in the parent directory for supporting vis.

If anyone has any information or thoughts on this topic, I'd be grateful for your help. Best,

Mark