executable process persist after X (closing) window

[richjoh]

You guys suggestion for app close event with Quit Application works as described but doesn't handle the case when the VI is aborted then is closed via clicking the X on the window panel.

So I'm wondering how that situation can be covered. The running VI is first aborted (stop sign icon) then the VI is closed via X on the window panel. I don't want ever want the executable "hanging" (in the windows process) after attempts to close it.

[JÞB]

---

@richjoh wrote:

 The running VI is first aborted (stop sign icon) then the VI is closed via X on the window panel. I don't want ever want the executable "hanging" (in the windows process) after attempts to close it.

---

NO-
NO-NONONONONONONONO.

Do not even SHOW the user the "Abort" button.  "Stopping your vi by pressing the Abort button is like stopping your car by running into a tree.  It may work but, it will have negative consequences"- LabVIEW Proverb

[richjoh]

I don't believe the X close operation is in agreement with all other UI running on a PC. It appears, the action of abort button followed by X button click is two consecutive aborts.

Yes abort button aborts the execution. I prefer to leave the abort button as is (otherwise why is it there). It's (abort button) the same as clicking X.  Its a convenience to abort the execution for the purpose of rerunning, everything works just fine due to initialization that occurs at start up. I now realize a few executable I created from scratch do this "hanging" persistently.

--Panel Close Event--

""

If a user closes the front panel of a VI that is not being called as a subVI and does not have any open references, LabVIEW aborts the VI. To ensure a Panel Close event case executes completely, be sure the application opens a reference to the VI before a user can close the front panel.

""

Now I don't have a reference open for my top level VI, even if I put one in, will this handle the case where the VI is aborted (using X or abort button)? Anyhow, the point is I need to perform a Ctrl+Q when the user click X. Ctrl+Q (from the File menu) shuts down LV executable.

[richjoh]

In fact, I don't need to abort the VI to cause this issue. Just let the executable run to completion and it ends with FP open. Subsequently click X to close the executable and it persist in the running process of Window XP. I'm unable to start another instance since the process still persist.

Its obvious that no event structure will fire if the VI has been run and FP is open (for re-running or closing). Ctrl+Q always shuts the executable down, clicking X on the panel needs a fix to address this problem.

[MoReese]

---

@richjoh wrote:

I don't believe the X close operation is in agreement with all other UI running on a PC. It appears, the action of abort button followed by X button click is two consecutive aborts.

Yes abort button aborts the execution. I prefer to leave the abort button as is (otherwise why is it there). It's (abort button) the same as clicking X.  Its a convenience to abort the execution for the purpose of rerunning, everything works just fine due to initialization that occurs at start up. I now realize a few executable I created from scratch do this "hanging" persistently.

--Panel Close Event--

""

If a user closes the front panel of a VI that is not being called as a subVI and does not have any open references, LabVIEW aborts the VI. To ensure a Panel Close event case executes completely, be sure the application opens a reference to the VI before a user can close the front panel.

""

Now I don't have a reference open for my top level VI, even if I put one in, will this handle the case where the VI is aborted (using X or abort button)? Anyhow, the point is I need to perform a Ctrl+Q when the user click X. Ctrl+Q (from the File menu) shuts down LV executable.

---

No, the abort button is not the same as the 'X' for panel close.  Perhaps in it's raw state, it may be, but your code can be designed to exit gracefully using the red X.  As Jeff stated earlier, you should never show the abort button to the user.  There is no way for the abort button to allow for a graceful exit.  Why would you ever want to abort a running program from within?  That makes no sense.  The abort button is there for development purposes only.  I only use it if my program locks up and the stop button or whatever other mechanism I am using fails to respond.  You wouldn't show the abort button to the user for the same reason you wouldn't display the run button.  Your program should startup and run when opened and exit gracefully when told to by the user.

[richjoh]

---

"Why would you ever want to abort a running program from within?  That makes no sense.  The abort button is there for development purposes only."

---

Wrong else I would not be able to include build an executable with an abort button or close it via click X. What you do is your preference, don't enforce your way of doing it on others. I also stated "Just let the executable run to completion and it ends with FP open (NO ABORT HERE). Subsequently click X to close the executable and it persist in the running process of Window XP."

I also paste the statement from the LV2010 Help menu and you will see the word abort in NI Help on FP Close event -  "If a user closes the front panel of a VI that is not being called as a subVI and does not have any open references, LabVIEW aborts the VI. "

[MoReese]

Well than you have a problem.  You want to fix something that you persist in doing against advise given to you by members of this forum.  Why are you aborting the program in the first place.  You said it yourself, this is where the application hangs up.  Well, don't abort it!  Why can't you exit using the run-time menu?  Why does your application "run to completion?"  Any program I have created is typically a looping program.  That's not to say there are not applications out there that would call for a single sequence routine.  Well, there I go again trying to impose my will on people.  I have to watch that.

---

@richjoh wrote:

---

Wrong else I would not be able to include build an executable with an abort button or close it via click X.

Just because you can doesn't mean you should.  The GOTO statement is still available in C++, but does that mean you should use it at all times?

What you do is your preference, don't enforce your way of doing it on others.

I'm just giving you some freiendly advise.  If your going to take it personal, your probably in the wrong place.  I don't care what you do, that's your headache.

I also stated "Just let the executable run to completion and it ends with FP open (NO ABORT HERE). Subsequently click X to close the executable and it persist in the running process of Window XP."

Yes, because the application reference is still open.

I also paste the statement from the LV2010 Help menu and you will see the word abort in NI Help on FP Close event -  "If a user closes the front panel of a VI that is not being called as a subVI and does not have any open references, LabVIEW aborts the VI. "

LabView aborts the VI?  How is this related to what you are doing by pressing the abort button?  Do you think they are the same thing?  The "does not have any open references" should tell  you everything you need to know.  So no, they are not the same function.

---

 

[SteveChandler]

---

@richjoh wrote:

I don't believe the X close operation is in agreement with all other UI running on a PC. It appears, the action of abort button followed by X button click is two consecutive aborts.

Yes abort button aborts the execution. I prefer to leave the abort button as is (otherwise why is it there). It's (abort button) the same as clicking X.  Its a convenience to abort the execution for the purpose of rerunning, everything works just fine due to initialization that occurs at start up. I now realize a few executable I created from scratch do this "hanging" persistently.

---

I always leave the abort button showing when developing code. When it is released the button goes away.

The abort button is there for debugging. It is your choice to leave it there in a finished application but to many people it might seem unprofessional or unpolished. For simple applications targeted to a specific set of users it might be ok as long as they are aware that they might need to use the task manager and are cool with that. As mentioned earlier the X is a Windows function that closes windows. LabVIEW has a specific default action that may or may not be what you want. The panel close event can and usually should be intercepted by LabVIEW code. You might only want to hide the window or you might want to shut down your application. The abort button is a LabVIEW thing that halts execution. As mentioned earlier it is like stopping your car with a tree. It is a very quick and effective way of stopping. If your shutdown code fails (breaks go out) it might be your only way of stopping. In that case the X is like calling the Windows tow truck to come sweep up the carnage left behind. It will probably leave some of the wreckage behind.

[richjoh]

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.

[SteveChandler]

LabVIEW does what LabVIEW does. It is more than opinion that abort is bad for end applications. There is a reason it is up by the other debugging tools. If you want LabVIEW to behave differently then you should put something on the idea exchange. If you think you found a bug you should write up a report and an example of how to reproduce it. Maybe you think the documentation is unclear in which case you might convince NI to create a documentation CAR.