LabView 6.1 executable raises "Application Exiting" event; Different behaviour as in development system

[2cv]

LabVIEW 6.1 Professional Development System
----------------------------------------------
I want to hide the main panel during execution. Therefore I set the property of the main vi "FP.Open" to FALSE, before the main loop with the main event-case.
In the development environment it works as expected, but if I build an executable and run it, an "Application Exiting" event is raised just after hiding the frontpanel. And the very strange thing is, that if you discard that event, it comes again, and again and again. No error is generated through the code.
I prepared an example that shows the problem.
If you start the VI within the development system
, the frontpanel disapears and after 3 seconds it reappears programmaticaly.
If you ran the executable, than immediately a dialog pops up with the information that a "Application Exiting" event appeared (see the source VI).

No I have some questions:
Why is the "Application Exiting" event raised ?
Why is it not possible to discard that event ?
Why does the executable behaves different ?

!!!! Attention !!!!!
If somebody has doubts to launch an executable posted in a forum, please build the executable new. The ApplicationBuild config file I used is also posted.

We had no problems to reproduce that problem on several machines.

The executable needs the 6.1 runtime environment.

[BiG-C]

Hi,

I too have noticed things with LabVIEW 6.1 front panels in executables. I tried to create a daemon VI that was dynamically loaded by a splash screen type of VI. When in the development environment the main VI could have its front panel removed and still operate, but building this into an executable and running it gave rise to application errors and windows memory dumps. What I just said might not be useful to your query but I thought I might let you know that my problem was solved with the Labview 7 front panel state property. You can define a front panel to be either hidden,standard, minimised or maximised states. And with this added feature to VI server, it pretty much suggests that there may have been problems with Labview 6.1 front panel manipulations.

G
oodluck!

[2cv]

Thanks for your info. It shows that I´m not alone with this kind of problem.
Nevertheless changing to LV7 is not an option for us. We need a working application now with LV6.1 and not in weeks or month. Ordering an update will cover weeks and needs money.

[Albert.Geven]

Instead of hiding you main panel, you could have a splash screen.vi that calls your main panel. after everything is loaded into memory via viserver calls.
In this way you simplify your problem.
One trick is to search OpenG for LVDT (labview development tools) from my collegue Martin Vernhout.
In these tools is a fastloader that can load your complete program bottom up to avoid searching vi's.

[BiG-C]

In reference to your splash screen loader, obviously the splash screen vi front panel will need to be hidden after the main program front panel is opened. But the problem is that we want the front panel of the main program to be closed also. Now when a LabVIEW6.1 vi is built into an executable it is as though at least one VI front panel must remain opened for the executable to remain alive. If you try to do this, it will either crash or silently close ( http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000DAA20000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0 ) This problem does not occur if you are running the VI within the LabVIEW environment. I believe it is a limitation of LabVIEW 6.1 as a front panel state can be defined as
either open or closed, and not hidden.

[2cv]

After talking with the german NI support, I got the info that´s a limitation of Labview. In an executable at least one panel must be open and if you set the panel property to "close" than it closes that vi and if it´s the main vi it closes the application. A workaround is the usage of the "lvwutil32" tools. That´s collection of VIs who are accessing the win32 API directly. These tool should be available available from ftp.ni.com