Strip Path VI error on exe version?

[SDR Kid]

Anyone having problems with the "Strip Path" VI not working on the Exe version of your application?  I've attached the culprit application with the file it should be reading, so save them to the same directory.  It should work fine as a normal VI, but then try to build it and it will error out.  The path window will show you that the "Strip Path" VI did not strip out the original file name of the VI, so it ends up appending the new filename on the end and it errors out.  I made sure the build was using the Storage Runtime Libraries.  Let me know if you have any ideas or options.

[tst]

This is normal behavior. In an executable (and in an LLB), the file itself is seen as a directory.

You can use the Application.Kind property to detect this, but my prefered method for this is to strip in a loop using a shift register and check the path using the File/Directory Info primitive and checking the Is Directory? output. You can see this in the Get Current VI's Directory VI from OpenG.

[Vasilich2004]

That is not normal behaviour. Who care about internal structure of LabVIEW? That is definetely a bug from any normal point of view.

[mikeporter]

I'm sorry that you don't like tst's answer, but it is correct. This is not only normal behavior, but the correct behavior also. If you ask a VI for its path it includes the complete path - including where it is stored. When you build an executable that path changes - as is well-documented in the various LV training materials that are available. If it didn't include the path to the executable that would be the bug. It's just one of those things that you have to think about when building executables.

Mike...

[Neil.Pate]

tst,

Any particular reason why you dont use the Application.Kind method? The only benefit I can see is that maybe it simplifies the logic as you don't have to strip the path a certain number of times depending on whether its a developement system or a run time system. I would be really interested to hear your reasons.

nrp

[tst]

---

nrp wrote:
tst,

Any particular reason why you dont use the Application.Kind method? The only benefit I can see is that maybe it simplifies the logic as you don't have to strip the path a certain number of times depending on whether its a developement system or a run time system.

---

Isn't that reason enough?

It simply guarantees that the code works regardless of whether you're using a standalone VI, an LLB, an EXE or any other combinations and options NI comes up with. As such, it seems like the only really good solution.

[Neil.Pate]

ok, I am convinced!

To be honest I just never thought of doing it that way before...

[Vasilich2004]

To mikeporter

Can you show me function from any C library (for example) that works differently in debug or release modes?

[10Degree]

V,

I hear your frustration.  You will have to come to grips with the strip path vi behavior, as I have, by considering the deployment model for labview exe's.  As tst pointed out above, an exe is a directory of sorts in labview when deployed as an exe.  Equally confusing with be the use of "current vi's path.vi" if you use that anywhere.  I have had the need to be able to return the application path (path in which the exe resides) from time to time in a portable and reliable way.  I found some solutions in threads herein (don't remember the exact ones - go search!), and came up with the attached VI.  Looking at this code may or may not help, but here it is nonetheless!  (version is either 8.2.1 or 8.5)

-cb

[astroboy]

Hi 10Degree,
May I have your attached vi in version 7.1? Thanks in advance.
Clement