Current Vi Path Function Behavior Usefulness

[N2TE]

Could someone help me understand what the usefulness or applicability is of the behaviour of the LabView "current vi path" primitive function when invoked from a vi that has been built into a run-time (EXE) application entity? I'm well aware of the differences of this function when invoked from both LabView environments ("development" vs "run-time") and how to subsequently compensate in the latter case.  I am familiar with the work-arounds and the appropriate number of "strip-path" operations needed to get the SAME path output in either case and how LabView subsequently treats the application file as a VI library.  I, as many others have done, have developed my own mechanism to handle the differences. But recently I discovered that there are cases where I must invoke the strip-path operation even MORE than 2 times as  documented on the NI site. I just had an instance where I had to invoke strip-path 5 times when in run-time/exe mode to get the same result as in development mode. It caught me by surprise.

So out of nagging curiosity for a long time and my own edification can someone tell me what the usefulness or applicability is with that function's output, un-altered, when in run-time/exe mode?  Why did the developers have it do this? In the case of my particular app that required a strip-path operation of 5 times, the un-altered "path" that came out of the function wasn't even remotely close to a valid path of any sort. So if the un-altered output of that function does not in fact have any usefulnesss in that one mode of operation and if everyone has to parse and extract the 'useful' information from the output, why would NI not fix it?  Why leave it the way it is? Are there other uses that I'm not aware of?  There may very well be a useful feature here I'm not aware of and I could be utilizing.  I'm here to learn.

Comments appreciated.

Thanks.
Eddie

[0utlaw]

Hello Eddie,

When building an executable, the on-disk hierarchy of subVIs is preserved within the exe- this means that if your subVI calling the This VI's Path primitive was once saved on disk five directories deeper than the top-level VI in the exe, the path returned by this primitive will reflect that. 

If you're looking for a location relative to the executable itself, the Application Directory primitive might be a better idea.

The primary use case I can think of for this would be to dynamically launch instances of a VI by path.

I don't think I've ever used this primitive in a deployed application, as the VI Path Property is much more versatile and doesn't need to be called from the VI in question. 

Regards,