LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Closing the Front panel

Solved!
Go to solution
Highlighted

@crossrulz wrote:

@James_W wrote:

Don't forget that in an Executable, closing the front panel of the main VI does not stop the process or remove it from memory.

you will need to call the 'Exit LabVIEW' function as well! (Found on the application control palette).


NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  That is 100% WRONG.  When all front panels are closed, the application will stop and the runtime engine will close.  So DO NOT use the Exit LabVIEW function.  And make sure all of your code is actually complete before that last panel gets closed because it will cause an abort (I have many years of experience debugging that issue).


Oh - I'm sure I was taught that years ago on a Basics 1 / 2 course and not working with a large enough team I have never been taught any different.

I always put it in as the last action in the runtime environment shutdown case to ensure all memory is released and everything is closed in case of thread hangs.

- didn't even get a comment on that when I only just failed the CLA 2 years ago.

I wonder what I've been missing all these years - looks like I need to take another look again.

 

Thanks crossrulz.

 

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2012 - 2016 installed
0 Kudos
Message 11 of 13
(212 Views)

Typically, for VI compiled to executable:

1) Disable the tool bar ( disable all the run/run-continuously things). Typical Windows application user do not understand those and will not use them correctly. Generally I would disable the menu also, since most of the entries do not help anyway.

2) Disable the Close Window X. Do not let user close the front panel window. VI is still running after clicking X to close the window, then the app is stuck... 

2.5) Add a stop button or something else on front panel to let user end VI execution gracefully. with all necessary closing cleanups.

3) Use Current VI's Path to get the path to this vi

4) Use Open VI Reference to get the reference to this VI, using the path in previous step.

5) In a Conditional Disable Structure, add subdiagram "Run_Time_Engine==true", use Invoke node call FP.Close  (using the VI ref in prev step) at the end of VI execution. This will close the front panel when VI finishes in the compiled exe, but will do nothing when running in LabVIEW development system.

0 Kudos
Message 12 of 13
(104 Views)
Highlighted

@LyLee wrote:

Typically, for VI compiled to executable:

1) Disable the tool bar ( disable all the run/run-continuously things). Typical Windows application user do not understand those and will not use them correctly. Generally I would disable the menu also, since most of the entries do not help anyway.

2) Disable the Close Window X. Do not let user close the front panel window. VI is still running after clicking X to close the window, then the app is stuck... 

2.5) Add a stop button or something else on front panel to let user end VI execution gracefully. with all necessary closing cleanups.

3) Use Current VI's Path to get the path to this vi

4) Use Open VI Reference to get the reference to this VI, using the path in previous step.

5) In a Conditional Disable Structure, add subdiagram "Run_Time_Engine==true", use Invoke node call FP.Close  (using the VI ref in prev step) at the end of VI execution. This will close the front panel when VI finishes in the compiled exe, but will do nothing when running in LabVIEW development system.


This message comes more than 2 years after the last reply in your thread.

 

I disagree with your points #2 and #2.5.  Normal user experiences with programs are that the X button is available and a means to shutdown a program.  It is rather odd to have the tools we typically use in LabVIEW such as a Stop front panel button.  (When you use Excel or Outlook, do you hit a Stop button to close them, or hit the big X in the corner?)  I do still include a Stop button on many of my applications and the users know what they are for, but if I want a truly Windows like experience, I don't put them in.  But I always have the Windows Close button enabled.

 

But you do have to handle the X properly. You need an event structure with a Panel Close? filter event.  Then you wire a True constant to the Discard? node and proceed to code that will stop any running loops, close references, and just have a orderly ending to your program.  Then you execute the Front Panel close method when all of that is done.

 

One other thing I do.  Think of how programs will not close right away if you have unsaved changes to the spreadsheet or document you were working on.  They'll give you an Are you Sure? type of dialog.  (You'd pretty mad if that long document you were writing was lost because you accidentally closed the window before you had a chance to save it!)  With so many windows open, it is easy to accidentally hit the wrong X that is for another window than the one you intended to close.  So if I have a program running that should stay open, like one controlling a test stand, then I make sure I incorporate an "Are you really, really sure you want to close this?" dialog in the Panel Close Event structure.  Either way I discard the event, but the result of that dialog box will determine if I initiate the cleanup sequences, or just ignore that the user had hit the Windows close button.

Message 13 of 13
(93 Views)