When should one use "Quit LabVIEW"?

[Bob_Schor]

I recently responded to a query from @TaraTech about using a Temp file located on a Server and having the file be "locked" when the LabVIEW code was converted to an Executable.  I wasn't able to replicate this finding, but I noted that I had not used "Quit LabVIEW" in my demo code.

I found another example of "Quit LabVIEW" in the Channel Message Handler template that ships with LabVIEW.  This is specifically surrounded by a Conditional Disable structure so that it is called only when running as a built application.

So why is this function necessary?  Under what circumstances should you use it?  The Help for this function says:

Stops all executing VIs and ends the current instance of LabVIEW.  This function shuts down only LabVIEW. The function does not affect other applications. The function stops all running

VIs the same way the Stop function does. If there is any unsaved work in memory, you will be prompted to save. Selecting Cancel will abort the quit.

If I'm in Development mode, and have a Project open and VIs that I haven't saved, I could see that if I were testing my code and executed a "Quit LabVIEW", this might prevent me from losing unsaved VIs (been there, done that!), but in an Executable, no VIs should be open, right?  [Hmm -- write an executable that does a "Quit VI" at 5 PM to make me go home and have dinner ...]

In my Projects with many parallel loops and "twisty little passages, all different", I try to ensure that no loops are left running when the code does a normal exit, and also try to anticipate (and code for) abnormal exits, as well.  Most of the time, however, it is the LabVIEW Development system that seems to hang while I'm testing or debugging code, and often times Ctrl-Alt-Del doesn't work, so I try to do a Shutdown/Reboot, and if that still doesn't work, I hold the power button until the machine shuts off.  

Wait a minute -- if I read (and believe) the Documentation correctly, this might mean that executing this function will "shut down only LabVIEW" -- does this mean it shuts down the Development System?  If so, why would you put such a function inside a LabVIEW Executable with (as in the CMH Template) so that it functions to kill the Development System (prompting you to save any unsaved work)?

Time to stop my head from spinning and listen to Wiser Counsel. Humbly,

Bob Schor

[DerrickB]

> eat grue

It has to do with how LabVIEW decides to shutdown an application, namely that VIs have stopped running and front panels are closed. A lot of the examples rely on a "Stop" button that stops execution but leaves the front panel open, Quit takes care of that case. If you make a simple VI that does nothing and just stops running, the executable stays open, which can seem odd for an executable.

If you do a bunch of async stuff, there's a lot of state management that can go wrong when trying to ensure they're all stopped properly and perhaps the user is trying to close the application because something isn't working properly and they want to restart it. You might get the main UI closed but the executable becomes a zombie, maybe with an icon still on the taskbar but probably just visible in task manager. Maybe there's a front panel that's open but hidden so there's nothing to show on the taskbar but the app isn't closed.

If you perfectly manage state, get all VIs back to idle state, and all front panels closed, then you technically shouldn't need it.

[Bob_Schor]

Thank you, Derrick.  That makes perfect sense.  I'm currently developing an Application, which I have built and made as sure as I can that everything shuts down.  One of the last things that I do (on the Host) is to have it close its Front Panel and any other open Windows I might have spawned (for displays and charts).  I just didn't realize that "Quit LabVIEW" also means "Close the @**#!#% Front Panels, Dummy!"

Bob Schor

[billko]

This is probably one of the most needed topics I've read in a while!

[rolfk]

My applications never use it! If they don’t shutdown properly because of stuck loops or asynchronously started VIs as background daemons, that’s a bug that needs to get properly fixed, not covered up by slapping a Quit function somewhere!

[billko]

---

@rolfk wrote:

My applications never use it! If they don’t shutdown properly because of stuck loops or asynchronously started VIs as background daemons, that’s a bug that needs to get properly fixed, not covered up by slapping a Quit function somewhere!

---

I'm questioning the validity of what is being said in this topic because this link seems to show the opposite of what was discussed in this topic, which is, using "Quit LabVIEW" a graceful way to stop an executable.  And the help says it's like clicking the abort button.

[rolfk]

It’s both valid. What Derrick describes is the conditional execution of Quit as absolutely last thing in an executable. If nothing is left over running (which SHOULD be the case in a well behaved application) it simply closes all open (and hidden) windows and that terminates the application either way.

If.there is some rogue loop still running somewhere it will be brutally yanked out of whatever it is doing, without any chance to collect 200 bucks passing by start and cleaning up behind itself about any resources it may have allocated and/or locked.

Yes it behaves like the abort button but if that is done after every loop has terminated and all resources have been properly closed and freed it is aborting nothing else than itself (and closing all front panels on the way out).

But it is a quick and dirty hack to “fix” an application that doesn’t always properly terminate every loop and actors/background daemon when it is supposed to quit. Or the programmer is just to lazy to make each front panel window close itself on terminating.

And there are situations possible where that application may still not quit, despite calling Quit, for instance when it is stuck in a non timeout kernel driver call. Such calls need to be signaled to end and that would be the task of the according close function for that session, but if you abort the app that session is lost and the application control is stuck in there for eternity (or you force close the application in Windows task manager, or in very pertinent cases restart the computer).

[AeroSoul]

So in a properly shut down application, the Quit LabVIEW function would work akin to a Front panel close property node?

[rolfk]

---

@AeroSoul wrote:

So in a properly shut down application, the Quit LabVIEW function would work akin to a Front panel close property node?

---

Maybe more than one, as each front panel needs to be closed for the application to terminate, including hidden ones from actors or similar, but yes your assessment is 100% correct.

[wiebe@CARYA]

---

@AeroSoul wrote:

So in a properly shut down application, the Quit LabVIEW function would work akin to a Front panel close property node?

---

I'm a bit lost here.

Closing a VIs front panel doesn't mean it stops running.

A VI is removed from memory when there are no more references to it. Closing it's front panel can cause this, but if the VI was dynamically started or if it explicitly opened a reference to itself, closing the front panel will not stop it.

Quit "stops all executing VIs and ends the current instance of LabVIEW." It doesn't explicitly close panels at all. 

Still wander why Quit LabVIEW has EXIT in it's icon...