Built exe not executable

[t0mt0m]

Hello everybody,

my first post in this great forum is sadly a problematic one. Before posting I made some google searches and forum searches, but I have found no answer to my problem.

I developed an application with Labview 7.0 that runs perfectly in the dev environment. The version I made a few days ago works perfectly as source and as exe. Then I made some changes (changed some IMAQ functions to plain array functions to gain a speed increase - so nothing speacial....). The source still works perfectly in the LV dev environment and I can build an application with the internal LV application builder from my source with all needed dependencies (just "plain" c dlls). But when I start the exe the front panel appears followed by this message:

"The vi is not executeable.A full development version of labview required to fix the errors."

Also the run arrow is broken.

In the official forum I found a hint that only relates to LV 6.02 but nevertheless I followed the instructions (1. save all; 2. Save with options (app. development); etc). Also I opened every single vi - all work, no dependency errors, no warning.. nothing. A mass compile runs without any problem...

I don't know what I can do else, so I hope you guys have an idea, what I can do.

Thanx in advance for your help.

Greetings

Tom

[m3nth]

I may be missing something here but your application shouldn't compile if you load it in the development environment and the run arrow is broken. Or if you force a recompile (Ctrl+RunArrow) and then it's broken--in neither case should you be able to compile.

So if you can load it in the Development Environment and the run arrow doesn't break, and you can compile it, but when you open it up and it's broken, that means it couldn't find something that was supposed to be there. Your DLL's I'm assuming. Or perhaps you have different DLL versions that cause it to break?--One that's being loaded by the development environment and one that's being loaded by the executable?

That's what I would check into--where are your DLL's, where are they supposed to be, and are any of them different versions with the same name.

[t0mt0m]

Hi,

thanx for your help.

I may be missing something here but your application shouldn't compile if you load it in the development environment and the run arrow is broken.  Or if you force a recompile (Ctrl+RunArrow) and then it's broken--in neither case should you be able to compile.

So if you can load it in the Development Environment and the run arrow doesn't break, and you can compile it, but when you open it up and it's broken, that means it couldn't find something that was supposed to be there.  Your DLL's I'm assuming.  Or perhaps you have different DLL versions that cause it to break?--One that's being loaded by the development environment and one that's being loaded by the executable? 

That's what I would check into--where are your DLL's, where are they supposed to be, and are any of them different versions with the same name.

5226[/snapback]

that's the strange thing. The run arrow isn't broken while I work in the development environment. I tried a recompile as you mentioned (Ctrl+RunArrow) and it compiled perfectly, but the exe i generated from the recompliled code has a broken one.

So I'm gonna check now all dll dependencies. Hope it works.

Greets

Tom

PS: Sorry, when my english sometimes sounds a bit strange, but it's not my native language...

[i2dx]

my guess is:

you use a relative path from your main VI (via the this-VI constant) to your dll.

when you build an exe, you have to "double stripp" your path, because an exe is like an llb, and the result of "strip path" with the "this VI constant" as input gives back the path to the llb/exe and not to the directory where the exe is ...

[m3nth]

i2dx,

I understand stripping off the executable.llb name once it's compiled but that would just be wired to a DLL argument, which wouldn't break the VI. It might make it not work right at runtime, but it wouldn't keep it from running.

What would break the VI is in the properties box of the Call Library Node--if the library listed could not be found or was loaded from a different location (different version).

[Rolf Kalbermatter]

my guess is:

you use a relative path from your main VI (via the this-VI constant) to your dll.

when you build an exe, you have to "double stripp" your path, because an exe is like an llb, and the result of "strip path" with the "this VI constant" as input gives back the path to the llb/exe and not to the directory where the exe is ...

5241[/snapback]

The path in a Call Library Node should be fixed up by the application builder automatically when building the executable. Basically if the DLL path is absolute AND points outside of the Windows or System directory the application builder will automatically add the DLL to the support file group which gets into the data directory by default. The Call Library Nodes in the executable will be adjusted accordingly to search for the DLL in that directory first.

The problem is if you use a relative path, which LabVIEW for some reasons does turn into an absolute path always but still remembers that it is relative it would seem to me. Then LabVIEW will search the directory where the VI containing the Call Library Node resides. If that doesn't bring anything it will pass the request to the OS which under Windows will search the directory of the executable asking for the DLL (e.g. the build application or labview.exe in the development system), then the Windows and System directory and last but not least any directory in the PATH environment variable for the current user.

All DLLs to be found in the windows or system directory are NOT added to the application build.

Rolf Kalbermatter

[t0mt0m]

Hi everybody,

I found the bug who has stopped my application from working as exe.

I have made a vi, that get's a reference as input parameter. This ref have I connected to a property node to get some properties. My big mistake was, that I forgot to connect the "error out" from the property node. So after connecting the property node's error out, the application builder dropped me a line, that there's an error in a sub vi what he didn't with the unconnected error out.

Maybe it's a tiny bug in LV7.0 - but I'm not sure....

So remember to connect every time the error out I will never forget it again

Thanks alot for your help.

Greetz

Tom