LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
tst

Add an easily accessible way to close an application

Status: New

Anyone building an executable in LabVIEW probably ran at one point or another into the situation where you exit the app, but the window stays open. So, you do some research and find out that you can call the Quit LabVIEW primitive () or close all the windows in the app to make it really exit. If you add the Quit LV primitive, you then probably encounter this - you test the app in LabVIEW, then when you stop it, LabVIEW suddenly disappears, requiring you to add code which will only call the primitive when you're running as an executable.

 

So, what if LV had an easier way of handling this?

 

Here are some options:

  1. Add another primitive which will only work in EXEs.
  2. Add an input on this primitive which will tell it to only work in EXEs.
  3. Add a VI to the palettes which will wrap this primitive and allow the user to select when it's valid (default - only in EXE). That VI can also have an error input. This is the method I use today (the VI is in user.lib), but it would be better if NI shipped this VI.
  4. AND MUCH BETTER - executables should exit by default when all visible VIs finish running. Thanks Randy.
Message Edited by Support on 04-12-2010 09:26 AM

___________________
Try to take over the world!
10 Comments
somebody_that_i_used_to_k
Trusted Enthusiast

Current method, a la #3:

 

ShutDown.png

 

I would welcome this Idea for it's cleaner syntax and better design-time behavior. I like solution #2 or #3, where #3 has an array input of the same type as the output of the App.Kind property (which happens to not be a typedef 😞 ).

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
crossrulz
Knight of NI
I'm full up for option 2 with the current primitive having the error terminals (you have to enforce data flow somehow).

GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
RandyP
Member
Wait, why not implement this the same way "Run when opened" is implemented? That is, either through VI properties (for VIs) or the build spec (for exes). Any reason that wouldn't work?
Message Edited by RandyP on 04-09-2010 03:06 PM
-Randy
-=--=-=-=-=-=-=-
Nothing like a good dose of LabVIEW to cure what ails ya'.
RavensFan
Knight of NI
I don't understand how you are correlating this with "Run when opened".  Two completely different things.  Run when opened, causes the VI to run when opened.  Exit LabVIEW (or not exiting LabVIEW) is something that is determined progammatically during the course of the code running.  A VI property is something that affects an entire VI.
tst
Knight of NI Knight of NI
Knight of NI

I think I understand what Randy's asking for, and it actually makes sense - The default behavior in an EXE should probably be to close all windows and terminate the process when all the visible VIs finish execution. I've never encountered an application which stays open when you exit it and I don't see why LV apps should be different.

 

This is actually simpler than my suggestion, in that you don't have to add explicit code, just have the VIs finish running. This could then be configured to have the current behavior (don't close the window at the end) by using a non-default build spec option.


___________________
Try to take over the world!
jmorris
Active Participant
I agree with Randy and tst; it seems redundant to have to add any type of code to every one of our executables when we always want the same thing - to close fully when done.
CrystalTech
Member
Great Suggestion!  Simply put (and I'm probably being redundant), as an application (in Windows, Apple, Linux, etc) it fully closes.  In source code mode, it only stops running.  Keeping it "Simple and Smart".
silmaril
Member

I gave kudos for this idea, but I'd like to propose one small change:

4. executables should exit by default when all visible VIs finish running.

 

I don't want my application to get killed while it's still busy saving data to the hard drive.

 

 

@JackDunaway:

Be carefull with the method in your example code!

You should clear the error cluster before trying to read the App.Kind property.

Your code will leave the application window open, if an error occurs anywhere in your shutdown code.

BTDT 🙂

 

SteenSchmidt
Active Participant

My kudo depends on that LabVIEW shouldn't exit when all visible VIs stop executing, but it should stop when all VIs stop executing. Or else you can't wait for a UI-less demon to stop. At least such a functionality should have the option to wait for UI-less VIs as well.

 

But a good base idea nonetheless.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
Mads
Active Participant

Kudos. Today's solution is not intuitive.

 

One of the things that made me never use the existing Quit LabVIEW-function (apart from the fact that the name should be something more generic, like "Quit Application" (...it's not LabVIEW to me when it's my own built application)) was that you could see the VIs stop and show their toolbars etc. shortly before the application would terminate. It made it look amateurish.

 

I cannot see this effect anymore. I'm not sure if that's because the behaviour has been refined (sometime between version 4 and now 🙂 ), or if it's because the computer's have gotten faster...(?).