Strip Path VI error on exe version?

[djs_at_eaton]

This VI should work.  Place it immediately after the call to "Current VI's Path."  It will have no effect in the development environment, but will return the correct folder when the VI is used as an executable.  It's in LabVIEW 6.1.

[tst]

I really don't see why go through all those hoops when this way really is quite simple. Obviously, this is just a quick example (6.1) to show the concept.

[djs_at_eaton]

I'm not sure which of our methods "jumps through more hoops," but tst's method doesn't require a VI to be in the "root" folder of the program.  My method was written for the case where the VI finding the path is in the same folder as the executable.  Either method will eliminate the EXE problem.

[tst]

---

@djs_at_eaton wrote:

tst's method doesn't require a VI to be in the "root" folder of the program.

---

Which is exactly why it jumps through "less" hoops - write once, test once and then you're done - you can use this with any VI you will ever have, on any platform, as long as NI doesn't change anything really basic, and if they do, you can probably incorporate the fix in a single place.

[sture]

I sometimes use NI Teststand and from TS calls .vi:s. It seems that "call chain" doesn't return the top-vi when called from TS, anyway the "open vi reference" returns an error in this case.  I solved the problem by using "current vi path" and strip the path one level then check if the extension is .exe or .llb.
What's the reason for using "call chain", I mean if it is a built application all the vi are "saved" directly under the .exe or am I wrong ?

[tst]

I never worked with TS, so I can't offer any ideas on that, but in any case, the loop method is more robust, even if you start with the Current VI's Path primitive.

---

sture wrote:

...if it is a built application all the vi are "saved" directly under the .exe or am I wrong ?

---

a) Not always. Sometimes you make dynamic calls. Sometimes you might call VIs in classes and those are saved outside the executable.

b) Even in cases where all the VIs are saved in a flat structure in the EXE, the looping method is better because it covers all cases (e.g. it works in the IDE as well, NI will probably change the EXE structure in the future, etc.). If you were asking about the call chain primitive specifically, the reason for using that is that you can then move this entire thing into a subVI, place it anywhere you want or make it a reusable VI.

My own reusable VI for this has more functionality than the quick example I posted, but the concept is the same.

[Alagar]

Hi TST,
will you make your ideas some what clear...
I cant understand that....

[tst]

I don't understand the question. You should ask a complete one.

[Alagar]

hi TST,
You have mentioned that  Current file path is not usefull in getting the vi path in Exe...
can you explain me why is it so?

[tst]

The Current VI's Path primitive will work correctly in an executable, but it might not always work the way you expect in all places.

Currently, if the VI is built into the executable, its path is <path to EXE>\VIname.vi.
If you call it dynamically and don't add it to the build, it will be whereever you call it from.
If it's part of a class, it will be in another folder.
When you run it in LabVIEW itself, it might be in a different folder than the top level VI.

The reason I used the call chain in my example is that it always returns the path to the top level VI and so allows you to place all the code in a subVI (although this actually will not work if the VI is called dynamically).