EXE external VI does not function with internal LV File Dialog VI

[cowen]

Hi Guys,

I have an EXE that was working well when compiled with LV8.2.1. I have now upgraded to LV2011SP1 and compiled a new EXE. The code is mostly unchanged with only some small modifications to correct dynamic paths. Generally this works well with one exception.

My application calls an external dynamic VI that in turn calls functions located inside and outside of the EXE. My build script is configured to 'Always Include' all VI's in a specific directory (my library). This works well with all functions I have tested except one.

I have an internal VI called 'find_file.vi'. This VI calls the 'File Dialog' function in the 'Advanced File Functions' pallette. If my external VI calls this function, then launching of the external VI fails. The 'find_file.vi' is only used by external functions, however, it is located in my 'Always Include' directory.

If I call the 'find_file.vi' from my main.vi (in a case structure) and recompile the EXE, my external VI works well. So, I have a work around solution but I hate 'work-arounds'!!

Any idea why in LV8.2.1 the file was correctly included in the EXE, but in the LV2011 build it appears to be excluded (or there is a path problem or...)?

I hope the above makes sense. Any help would be appreciated.

Regards

[ShaunR]

The structure of file paths in the exe layout changed after 8.x. You could try checking the 8.x layout to see if your problem goes away and, if it does, it will confirm it is a file path problem.

[cowen]

Hi,

Thanks for your response and you are correct. Clicking the '8.x' format check box allows everything to work again. So the problem is related to path. It has nothing to do with the 'File Config' function, the problem is only that the path to the VI appears wrong if the main VI (or other internal VI) does not call this included function.

The easy fix is to click this box and everything works for now. However, if I then start to use classes in this application and use dynamic despatching, I will have VI's with identical names and the compiled code becomes horrible with additional folders being created for files with duplicated names.

This is not really the solution I would like to use. But at least we know a little more now.

[asbo]

The alternative to the 8.x layout is to just put in more debugging code where the call is failing, figure out what it's expecting, what it's using, and then fix it.

[Aristos Queue]

We changed the EXE format specifically to deal with the "multiple VIs have the same file name" issue. Turn the compatibility mode off, fix your paths, and then the system should start working for you. One function you need to know about is "Application Directory" -- it's a node in the palettes. In the development environment, this is the same directory as your project (assuming you're in one) and in the built-EXE, this is the same as your EXE. This makes writing dynamic load code a lot easier. If you want to dynamically load VIs that are part of your EXE, just calculate them as relative paths from your top-level VI. The same relative paths will be maintained inside the EXE as you have before you build the EXE.

[cowen]

The alternative to the 8.x layout is to just put in more debugging code where the call is failing, figure out what it's expecting, what it's using, and then fix it.

Where to insert the debugging code? I have checked all path issues with regard to my external VI and this is correct. If I replace this external VI with a simple VI that provides a 'Hello' pop-up, this works perfectly. If I replace this with a version of the file that calls a VI from inside the EXE (but not called by an EXE VI), the external VI can not launch. It should.

Aristos Queue, all paths that I have control of are correct using the standard functions!! The problem is that the EXE does not know the path to a VI within itself. The external dynamic VI's are working and being called from the correct location. The internal files are not being called dynamically but directly.

[cowen]

Further on this topic. I have spoken with NI and they are escalating this to their R&D in the States. Hopefully I will have an explanation soon.

The suspicion from NI in the UK is that there was a conscious decision to change the support of this functionality in a compiled EXE with later LabVIEW versions. Not nice!

[Wire Warrior]

One function you need to know about is "Application Directory" -- it's a node in the palettes. In the development environment, this is the same directory as your project (assuming you're in one) and in the built-EXE, this is the same as your EXE. This makes writing dynamic load code a lot easier. If you want to dynamically load VIs that are part of your EXE, just calculate them as relative paths from your top-level VI. The same relative paths will be maintained inside the EXE as you have before you build the EXE.

Okay let me see if I have this straight. The 'Application Directory' will give me my .lvproj file directory path in the IDE and the .exe file directory path in the Run Time Environment (RTE). Did I state that correctly?

[hooovahh]

Okay let me see if I have this straight. The 'Application Directory' will give me my .lvproj file directory path in the IDE and the .exe file directory path in the Run Time Environment (RTE). Did I state that correctly?

I just did a test and that is exactly how it works. I did not know that feature either. Normally I would use the OpenG VI "Current VI's Parent Directory" which will keep going up a folder until it finds a real folder (not a directory in the built EXE).