file path problem

[Harold_Timmis]

I have looked an read through almost all the file path problem post possible and I am still having issues maybe one of you guys can help me, here are my files

I am doing this as an example so that I can apply it to all of my file problems....

[LV_Pro]

It would probably help if you described the issues your having rather than just posting some code. In the example that isn't in the .exe build you get a "file not found error", due to parsing the filepath one time too many, which I assume is to deal with the problem of an exe adding one extra level. Not sure what issue is occuring in the exe, it doesn't run for more than an instant, nor provide an error message.

[smercurio_fc]

Why Does My Executable Not Work When Using the Current VI's Path Constant?

[Harold_Timmis]

well i am stripping the file and it is still not finding it and it is also driving me mad lol, i strip it twice it does not find it i strip it once it does not find it i am really confused

[Harold_Timmis]

I have read through that link several times and tried to strip the path twice I still don't get the correct end result ie the string indecator with the files string in it

does anyone have an example project where this works, so I can review it and figure out my mistake.

[CoastalMaineBird]

I always use VIs in LLB files to avoid such problems.

That way, it works either way: in the DevSys, or in an EXE. 

If you are in SomeFolder\SomeLibrary.llb\SomeVI.vi, and build an app in 

SomeFolder\SomeProgram.exe\SomeVI.vi,

Then CURRENT VI's PATH returns 

    SomeFolder\SomeLibrary.llb\SomeVI.vi

or SomeFolder\SomeProgram.exe\SomeVI.vi

Strip it ONCE and you get 

    SomeFolder\SomeLibrary.llb

or SomeFolder\SomeProgram.exe

Strip it TWICE and you get

    SomeFolder

or SomeFolder

But you don't know (or care) whether you're in a LLB or an EXE. 

[LV_Pro]

First of all, to troubleshoot the problem it would help to put some filepath indicators at each point so that you can see what is going on. Also, in your exe having an error dialog "Simple Error Handler.vi" to let you know what LabVIEW didn't like in the exe.

Now, when you run a top level ("Main.vi") and use the "Current VI's Path " in the development mode it returns <Filepath>\"Current path"\Main.vi. So stripping once will get you to  <Filepath>\"Current path" .    Now if you make it into an exe the "Current VI's Path" returns <Filepath>\"Current path"\"Name.exe"\Main.vi so you are "nested" one deeper.

I use the following construct to determine whether the vi is being used as in the development environment or as an exe, the parse the path accordingly, although in this instance it is used to supply different directory names to a little more complex file system.

[TCPlomp]

I strongly advise you to install the OpenG tools. (howto).

The OpenG toolkit has a function called 'Current VIs Parent Direcory', which always returns the actual folder a VI is located in. In LabVIEW 2009 the number of strips inside an executable can 10 or even more. Using the OpenG VI will automatically deal with this.

Ton

[Harold_Timmis]

I try to install it before and it wouldn't allow me I am running vista with a 64-bit system

[LV_Pro]

My question is, under what circumstance do you see so many "strips" in 2009? And to Harold, are you running the 64 bit version of LabVIEW? I've been led to believe that it  doesn't have some of the features (yet) that the 32 bit version has.

The OpenG toolkit is handy, as well as being very educational as to how some really bright LabVIEW folks have resolved various problems.

The key in this case is definitel whether you are in development mode or exe. It is also a good idea, when trying to resolve a problem like this, to put in some "debug tools", like indicators that you can see when it runs, or, as I have done in some "ugly problems" written a sub-vi that logs results at various points to a file. This can even be left in the program with a flag in the programs ".ini" file indicating whether to enable debugging or not.