Auto-terminate UI Loop on OS Window Close

[The_Seeker]

Ok, here's my suggestion: 

One minor annoyance with building pop-up subVIs is gracefully terminating the UI execution loop if the user closes the panel using the standard MS Windows "X" close button (upper right-hand corner of all standard Windows panels.)

Of course there are at least a couple of work-arounds -- disabling the Windows functionality completely, or polling to see if the panel is still open using a property node (and programmatically exiting the loop if it isn't). But I was thinking it would be nice if there was an option in the pop-up menu that forces a loop to terminate if the front panel window changes state from 'open' to 'closed'.

Alternatively, there could be a check-box option in the "Window Appearance" catagory of the "VI Properties" dialog that is something like this: "Auto-terminate loops when front panel closes". 

It's nice to offer users the familar functionality of the standard OS close buttons, but it would also be nice if there was a simple way to do this, without the programming overhead. (I've enclosed this functionality inside a subVI and it's relatively easy to drop this in and wire it up. Presumably, it wouldn't be too much work to add this capability right into the loop structure itself.)

I realize that this leads to questions about what to do with parameters that are usually passed when the loop is terminated in the 'correct' way -- the whole question of "OK" versus "Cancel". Perhaps Windows itself has a an answer to this question, and that could be adapted into the LabVIEW environment.

Anyway, it would sure be nice if there was a way to enable the standard OS close boxes without incurring the minor annoyance of programmatically terminating an active (while) loop or UI state machine after-the-fact.

Anyone agree?

[RavensFan]

I'm not sure what you are asking for here that isn't already present in LabVIEW.

Use the Panel Close? event to detect the X button was pressed.  Discard the event, and do whatever you need to programmatically to shutdown loops, close out references and resources, and otherwise exit the program gracefully.

[The_Seeker]

The point was to make this a configuration option, rather than something that requires additional programming.

I see your point though that it's not a huge deal to program in this functionality (-- and as noted in the original posting, it's probably 'safer' to require the programmer to take control of the disposal of the loop), but for applications with several simple pop-up dialog/UI VIs, it just seems like a 'right-click' configuration setting would be that much quicker and easier.

Elsewhere in this forum,  I ran across a suggestion to put the items from the tools palette into the toolbar. In my opinion, this is a GREAT suggestion -- not because it adds something that doesn't exist in LV, but more because it would make our lives easier in the day-to-day programming tasks. 

To underscore the point of the original posting, consider that the majority of the options in the pop-up menu can be programmatically modified by property nodes, yet there are in the pop-up menu -- presumably to provide useful shortcuts for functionality that is used frequently. 

I hope this clarifies the nature of the original posting.

🙂

[RavensFan]

I don't think there is a big use case for what you propose.  Current behavior is that LabVIEW just aborts when the panel is closed.  You want all loops to finish and terminate when the panel is closed.  You don't want to do anything to clean up references or close files beyond that?  Anything like that would certainly need additional programming.  If you don't need that, then why would you care if the loops finish?  Just go ahead and let the program abort like it is doing now because you aren't doing any special programming in your distinction between allowing the program to continue onto the next iteration (like it would do if you didn't close the panel?) or allowing the loop to finish and then end the program.

It would be like if your boss said I'm giving you 50 tasks to do.  If you finish them, I'm happy, I'll take the results.

Then later he comes back and says,

1.  I want you to stop, you're in the middle of task 45?  Well just throw all your work away.  (Current behavior)

Or 2.  I want you to stop, you're in the middle of task 45?  Well finish that step, then throw all your work away.  (What you propose.)

Or 3.  I want you to stop, please finish task #45, file away your paperwork, and clean the crumbs from your snack off your desk.  (The current behavior if you use panel close?  and discard the event and do clean up work before ending the program.)

Why would you ever need to do #2, if the results are going to be the same as #1?

[The_Seeker]

What I was looking for is behavior number 1 -- according to your comment, this is the "current behavior". 

I'm confused by this comment, as it has been my experience that the VI just chugs along, locked in the loop, with the window closed. The loop doesn't terminate at all. If the calling VI is waiting on the termination of the subVI's loop, this can be problematic -- it appears that the caller has simply locked up.

Perhaps there is a disconnect between what I'm trying to communicate and your perception of the problem I am expressing. Or maybe the default behavior has changed and I was not aware of it.

In any event, the "right answer" is probably behavior number 3 anyway, so perhaps there is no way to do this by means of a simple configuration. (I just get annoyed every time I must duplicate the same Window management logic in each pop-up up dialog VI. It would be nice if this repetitive task could be automated in some simple way.)

[RavensFan]

---

The Seeker wrote:

I'm confused by this comment, as it has been my experience that the VI just chugs along, locked in the loop, with the window closed. The loop doesn't terminate at all. If the calling VI is waiting on the termination of the subVI's loop, this can be problematic -- it appears that the caller has simply locked up.

---

If you have an example where this is the case, please post it.  And tell what LV version it was.

Just to verify, I created a simple VI while loop with a wait statement and a Beep function.  Saved it (so I wouldn't get the save dialog).  Ran it got the beeps.  Hit the X, it closed and the beeping stopped.

Opened it again and made a slight modification so the save dialog would appear.  Ran it.  Hit the X, the save dialog box popped up.  It was still beeping, but once I said Don't Save changes, it closed and the beeping stopped.

Further information:  All that I did above was based on a VI that was the top level.  Reading your post again, I see you were talking about a subVI where you open the front panel and it has its own running while loop.  Testing it that way, I do see that the subVI continues to run.  Why?  Because you technically aren't stopping the VI, you are just closing its front panel.  It just so happens that if you close the front panel of the top running VI, it causes it to abort and leave memory.

I do understand your point about needing to do some "extra" programming in the dialog type of VI to handle the panel close event so that it behaves the way you generally use it and wanting to have LabVIEW take over that chore for you.  But I counter that there are other perfectly legitimate use cases where you may want the subVI to continue to run even if its front panel is closed, and it is up to the programmer who wants to use it that way to create is overall program architecture appropriately so that it doesn't create an application where it appears to be locked up, or has running code that has been hidden with no mechanism to stop it.

[G-Money]

Functionality is already in LabVIEW.