When should one use "Quit LabVIEW"?

[rolfk]

Several points to remember:

- A LabVIEW built application is terminated as soon as the last front panel is closed, even if the diagram has not terminated executing! Closed means closed, if it is hidden that does not count as closed.

- Quit LabVIEW aborts everything in the current application context but not necessarily everything, although you would have to go to some length to create multiple application contexts in an executable.

- When the diagram stops executing, its front panel is not automatically closed. You have to close it explicitly somehow.

- One option is to close the front panel through a method node. The other is to call Quit LabVIEW which will abort all VIs in the current application context and then close their front panel.

- But making sure to close all front panels explicitly (preferably as last step of the diagram of the last VI  to avoid the first point above kicking in) is enough to terminate an executable, as the executable process is automatically terminated by the LabVIEW runtime system as soon as there are no active LabVIEW child windows present anymore (there always is a hidden root window present but that is simply dispatching the OS events to the LabVIEW runtime root loop and the one entity monitoring if the executable has still any window open).

[JÞB]

I will typically use a Quit LabVIEW in a Case structure with App Kind = Run Time Engine after discarding a Panel Close? Filter event and running any cleanup. 

This allows the normal experience for the user to end the application with the Windows X.  Yet does not close the IDE during development.

I suppose I could invoke This VI FP Close instead inside the case structure.  I would avoid that unless I fully documented that anyone inheriting the code maintainance MUST follow the rules Rolf stated or risk unexpected behavior of the built app under some circumstances. 

I have found no use for Quit LabVIEW outside that specific case.

[billko]

---

@JÞB wrote:

I will typically use a Quit LabVIEW in a Case structure with App Kind = Run Time Engine after discarding a Panel Close? Filter event and running any cleanup. 

This allows the normal experience for the user to end the application with the Windows X.  Yet does not close the IDE during development.

I suppose I could invoke This VI FP Close instead inside the case structure.  I would avoid that unless I fully documented that anyone inheriting the code maintainance MUST follow the rules Rolf stated or risk unexpected behavior of the built app under some circumstances. 

I have found no use for Quit LabVIEW outside that specific case.

---

That's actually a pretty sneaky trick.

[wiebe@CARYA]

---

@billko wrote:

---

@JÞB wrote:

I will typically use a Quit LabVIEW in a Case structure with App Kind = Run Time Engine after discarding a Panel Close? Filter event and running any cleanup. 

This allows the normal experience for the user to end the application with the Windows X.  Yet does not close the IDE during development.

I suppose I could invoke This VI FP Close instead inside the case structure.  I would avoid that unless I fully documented that anyone inheriting the code maintainance MUST follow the rules Rolf stated or risk unexpected behavior of the built app under some circumstances. 

I have found no use for Quit LabVIEW outside that specific case.

---

That's actually a pretty sneaky trick.

---

I thought everybody knew that one.

It's dangerous though. If a dynamic process is still busy doing something, like saving configuration, it will be stopped doing that.

[crossrulz]

---

@JÞB wrote:

I suppose I could invoke This VI FP Close instead inside the case structure.  I would avoid that unless I fully documented that anyone inheriting the code maintainance MUST follow the rules Rolf stated or risk unexpected behavior of the built app under some circumstances.

---

Instead of using a Case Structure, use a Conditional Diagram Disable Structure.  It will eliminate the need for the property node and make life a little easier for the compiler.

[JÞB]

---

@crossrulz wrote:

---

@JÞB wrote:

I suppose I could invoke This VI FP Close instead inside the case structure.  I would avoid that unless I fully documented that anyone inheriting the code maintainance MUST follow the rules Rolf stated or risk unexpected behavior of the built app under some circumstances.

---

Instead of using a Case Structure, use a Conditional Diagram Disable Structure.  It will eliminate the need for the property node and make life a little easier for the compiler.

---

Conditional disable structures didn't always exist....;)

[JÞB]

---

wiebe@CARYA wrote:

---

@billko wrote:

---

@JÞB wrote:

I will typically use a Quit LabVIEW in a Case structure with App Kind = Run Time Engine after discarding a Panel Close? Filter event and running any cleanup. 

This allows the normal experience for the user to end the application with the Windows X.  Yet does not close the IDE during development.

I suppose I could invoke This VI FP Close instead inside the case structure.  I would avoid that unless I fully documented that anyone inheriting the code maintainance MUST follow the rules Rolf stated or risk unexpected behavior of the built app under some circumstances. 

I have found no use for Quit LabVIEW outside that specific case.

---

That's actually a pretty sneaky trick.

---

I thought everybody knew that one.

It's dangerous though. If a dynamic process is still busy doing something, like saving configuration, it will be stopped doing that.

---

As a rule, all parallel Message handling loops are guaranteed stopped by dataflow prior to calling app kind.  An ACBR fire n forget process would need to have some safety exit and collect status.  

Regardless,  it only gets dangerous when you learn enough to expect everyone else is smarter than you!

And, we LabVIEW ninja don't call call them "sneaky tricks!"

[crossrulz]

---

@JÞB wrote:

Conditional disable structures didn't always exist....;)

---

They existed at least back to 8.2 (farthest I can check).  Though, it looks like the "Runtime_Engine" was not a symbol back then.  I've been using this trick for at least a decade.

[rolfk]

---

@JÞB wrote:

---

Regardless,  it only gets dangerous when you learn enough to expect everyone else is smarter than you!

---

Actually that is not quite correct. But some people know enough to be dangerous, but not quite enough to realize that they are dangerous. 😀

[JÞB]

---

@rolfk wrote:

---

@JÞB wrote:

---

Regardless,  it only gets dangerous when you learn enough to expect everyone else is smarter than you!

---

Actually that is not quite correct. But some people know enough to be dangerous, but not quite enough to realize that they are dangerous. 😀

---

Hence, my preference for Quit LabVIEW! 😀 

It keeps me from looking like I didn't expect something like that from the next developer.