LabVIEW
Quit LabVIEW within Event Case crashes LabVIEW
A colleague of mine thought he was following good practice when he used the Quit LabVIEW function, as advised in the Core Materials, to exit his built application. Unfortunately he placed it within an Event Case.
The end result? DAbort 0x8AAA1713
Lesson: Don't call Quit LabVIEW until your code has finished. Certainly don't call it within an Event Structure. Perhaps NI can improve on the handling here to prevent this nasty behaviour?
I never use Quit LabVIEW. If the application doesn't stop without that primitive it is a bug!
I did run into a funnyness with this however! I had a deamon type application which runs headless in the background inside the IDE and for some reasons I wanted to catch the LabVIEW exit event to clean up before my deamon got murdered. Easily done by using the LabVIEW event structure and capturing the Application Exit? (in never versions it seems to be called Application Instance Close?) filter event. But if I dismiss this filter event by passing True to Discard because I want to pass control to the standard exit state of my state machine and then call Application Quit, this primitive will do nothing. For some reason the Discard is apparently stored globally somewhere, rather than only discarding this particular event and Quit LabVIEW simply does nothing. Maybe this is fixed in one of the latest LabVIEW versions, I originally run into this in LabVIEW 7 and verified it to behave like that up to 8.5 or 8.6 or so.
I thought I read somewhere that using "Quit LabVIEW" was essential in an executable built in LV 7.x. Is that true? Maybe that's where the practice came from. Still, I think it was recommended to tack it onto the end instead of having it in the event structure.
@billko wrote:
I thought I read somewhere that using "Quit LabVIEW" was essential in an executable built in LV 7.x. Is that true?
Some of my older programs still do that as a last step (stop if run in the development environment, but quit if an executable). I have never tested if "quit" is still needed in more recent version 😄 The "stop" is definitely still needed, because I use the [x] to stop the VI (discarded panel close event, no stop button anywhere!) and I definitely don't want to actually close the VI while developing.
@altenbach wrote:
The "stop" is definitely still needed, because I use the [x] to stop the VI (discarded panel close event, no stop button anywhere!) and I definitely don't want to actually close the VI while developing.
I just use a Conditional Diagram Disable Structure. In the Run_Time_Engine == True, I close the panel, essentially ending my application. In the default case I do nothing, leaving the front panel open, but execution is still properly ended (assuming the code was properly written). The Stop should not be needed unless you have other issues with stopping parallel VIs.
I use the "MGI Exit If Runtime.vi" in my top level VIs, of course only after gracefully stopping all other parallel loops/dynamically called subVIs. However, I am not sure if this is the best approach, or not?
@crossrulz wrote:
The Stop should not be needed unless you have other issues with stopping parallel VIs.
One of the problems is that you cannot have multiple discarded "panel close?" events. Once one random event structure sees and discards a "panel close?" event, the other event structures waiting for a "panel close?" will never see it. (I have at least one extra independent event loop, only dealing with UI cosmetics, e.g. to hide/show certain controls based on the state of other controls and react out of band, no matter what else is going on). This means that once the main UI loop completes, all other loops need to be notified in some way to also stop. In my case, there is no hardware involved and no defined shutdown order is needed for these other loops. The "stop" is my simple way to abort all other loops. Any other solution would require more complicated code.
