How do I determine VI file specification in Executable?

[Greg_S-Video]

Hello wwwbrown

I just wanted to verify that this issue has been solved to your level of satisfaction.  If you could let me know, I'd really apprecaite it!

Thank you for choosing National Instruments!

Greg S.

[ww.brown]

It is solved by virtue of the solution VI I included with my final post.  Thanks.

[Greg_S-Video]

Wonderful!  Glad to hear it!

Greg S.

[X.]

My attachment demonstrates the solution.  On the first call, you discover the trunk directory by trial and error.  Once you have found the trunk, it is valid for all other VIs in the application.  A future version of LabVIEW could facilitate this algorithm by providing the trunk directory with an application property node.  Hey, maybe LabVIEW does this already and I missed it!.

How does your VI work in case some of the subVIs are on a different partition or drive? Or more generally, how does LV handle that? This is a purely rhetorical question, as I don't really need the answer...

In essence the new approach tries to preserve relative paths, which is nice.

[ww.brown]

I have not encountered that use case so my VI does not handle multi-drive builds.  It took me 6 months to discover a good solution for single drive builds.  I have no idea what trunk directory to use when files in the executable come from different drives.  Good question!

[X.]

BTW, I just discovered this thread as I was myself struggling with a built using relative paths. I had not noticed that things had changed from LV 8 to LV 9 (and thus 2010). I find the relative path option (rather than flattening all paths as was done in LV 8 and prior) much easier (except potentially for this multi-drive issue).

I had developed my own "search path" VI at the time. My approach was slightly less clever than yours in the sense that each time I was dynamically calling a NEW VI, I would recursively search within the directories (I limited it to 2 levels up so that it would not take for ever when developping, but for a release, a larger number would probably have been fine). Then, I would store the path of the found VI for fast access next time it would be called (in other words, I was building a database of paths for dynamically loaded VIs). This would work with identically named dynamic VIs with a slight modification, I suppose.

My 2 cts/

[X.]

For what it's worth, I am attaching a slightly modified version of your VI. The difference is that I have renamed the inputs and outputs so that they are more intelligible (to me) and removed the "Executable Path Specification" input, which is not necessary (you can find that otherwise).

It can also be run during Development (as it will just return the same path that was provided as input).

I am using it within my own utility that searches for a dynamically launched VI by name (so no need for the full development path... Well not exactly, but that's a longer story).

My 2 cts.

[ww.brown · Accepted solution]

I have recently discovered a bug in my 3-08-2011 solution.  The revised solution is attached.

WB