LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

executable process persist after X (closing) window


@richjoh wrote:

The problem is not pressing the Abort button (your opinion on abort button doesn't change my opinion). The problem is pressing the X to close the executable after it has run. Please stay on this topic on this thread. I don't have a reference open to the TOP level VI, thus explained in the help, Labview aborts the VI.

 

The execution is run from start to finish, the user click X to close the finished executable window. The top VI is not being called by a subVI and all references are close LV should ABORT the VI and make it go away and not hang in the Windows process. If there is an open reference I have overlooked this could explain the hang up in process window.


 I don't have a reference open to the TOP level VI, thus explained in the help, Labview aborts the VI.  Yes, unless you catch the Panel Close? filter event, discard the event, and "apply the breaks" by allowing your application to run clean-up like releasing locks, resources, closing references and placing and hardware in a known safe state.  What if your application controlled a high voltage power supply? Did you mean to leave it on? Pneumatics? .  After the clean-up is complete and error checking is done to ensure safe operation (or warn the user of unsafe conditions) a quick call to the close application primitive discards the panel and tells the OS the application has closed.

 

The execution is run from start to finish, the user click X to close the finished executable window. The top VI is not being called by a subVI and all references are close LV should ABORT the VI and make it go away.   It does! it closes the vi and the vi panel but does not close the application that is executing the vi, the LabVIEW RunTime Engine closes when executable calls the close application primitive.  Thats just the way it works because, LabVIEW intended to allow the developer to allways have a means to exit with attached hardware in a safe condition.  This is Test and Measurement software- or started that way- but even MS office will delay application termination after hitting the X if shut-down conditions are not met (prompt to save ring a bell?)

 

On the other hand you seem to be saying that your top-level vi completes?  why did you not close the application programatically?  If you intended for the front panel to remain open so the user can observe results, enter a loop waiting for the user to close the application and close it as discribed above.  Most GUIs do not complete until the USER choses to close the application.


"Should be" isn't "Is" -Jay
Message 21 of 24
(866 Views)

Again, with some added information, the executable is built witih debugging enabled so this makes the FP persist after the executable run to completion. Another use is the FP indicates a visual record of step leading up the running the executable which is of use here. I'll go deeper, the user needs debugging enable on because I use a boolean array to choose 1 or many or all COM ports before the executable starts. It works this way out of incremental enhancements.

 

Once the executable runs to completion, the FP now persist, i.e. the code determines when set Stop is True and stops on its on. Now the user clicks X and the window is closed but too many times the executable persist in the Windows process window. So I expect LV runtime to close the process of the executable whenever the the window is closed.

0 Kudos
Message 22 of 24
(854 Views)

@richjoh wrote:

So I expect LV runtime to close the process of the executable whenever the the window is closed.  Again- The Runtime DOES close the process of the vi when the X is pressed.  What did you expect would shut down the run-time-engine? The App instance is not closed by merely unloading all vis!

"Should be" isn't "Is" -Jay
0 Kudos
Message 23 of 24
(846 Views)

Thanks for all the responses on this issue. The way to avoid this issue is disable VI debugging on the build, run your executable as such and handle the FP Close event.

 

I'll keep this in mind for the next task I get to perform.

Message 24 of 24
(821 Views)