LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Trying to Implement a Panel Close? Event

Solved!
Go to solution

Help a (relative) novice out here please. Long story short, I have a simple test program (attached) to figure out how to shut down an application programmatically when the user presses the Windows ‘X’. The problem is, the loop doesn’t iterate. I assume I’m doing something wrong with the Event structure, but due to old age or simple lack of knowledge, I can’t figure it out. Can any of you geniuses put me on the right track?

0 Kudos
Message 1 of 9
(1,731 Views)
Solution
Accepted by another_novice

Event structures only run when one of their frames is selected to run.  Until then the code waits on them. Loops don't run again until everything inside of them has completed, and because you don't have any other event frames, literally the only way for the loop to run is for you to initiate the panel close, triggering the one and only frame.

 

As an immediate short solution, you could just add another frame, set it to the Timeout event, and set a timeout.  Probably 500 ms to match your loop timer.  This would run that frame after 500 ms of inactivity.  That will work in the short run, but if you need to add any more events it could stop your whole loop from iterating.

 

In the long term it's best to have one While loop running just the event structure and nothing else, and have that loop send a signal to the main loop to stop when your program needs to end, or make any other changes to the state of the main loop.  That way your process and your event handling aren't able to lock each other up.

 

It might help to look at a post I made a while back about event structures:

 

https://forums.ni.com/t5/LabVIEW/Struggling-with-Event-Structures/m-p/4086346#M1176175

 

 

Message 2 of 9
(1,701 Views)

Great advice, thank you. Thanks also for the link to your post on Event Structures. Very informative.

0 Kudos
Message 3 of 9
(1,696 Views)

Yes, as suggested add a 500 ms timeout case to replace your 500ms wait.

 

There are several other issues that you might want to address:

 

  • You have a potential race condition due to blatant overuse of a value property node. There is no way to guarantee that the "Cum score" terminal has been updated in the current iteration BEFORE the property is read, so you might get a stale value. You need to eliminate the value property node and just branch the wire!
  • Writing a zero to that terminal via a local variable before the loop is way overkill because the terminal gets updated literally a nanosecond later, so that local variable is just a waste and completely pointless.
  • Your blue shift register is not initialized, so it might retain a stale value and the case might not always trigger on the first iteration. To ensure that, you should initialize with a sentinel value, e.g. "-1".
  • Using a change in "minute" seems fragile because the first TRUE can take anywhere from 0 to 59 seconds.
  • Your "SEconds" (sic) terminal has the wrong representation.
  • You can eliminate the lower case structure by placing the dialog inside the "panel close?" event.
  • Not sure why you think you need three zero diagram constant. One is probably enough. You can branch the wire.
  • Your random number is not "fair", because edge values (i.e. 0 or10) only have half the probability of the others.
  • I would not hide terminals in inner structures
  • The default input for "seconds to date/time" is the current time. No need to get and wire it. delete the "Get date/time in seconds".
0 Kudos
Message 4 of 9
(1,696 Views)

I appreciate the tips. Thank you.

0 Kudos
Message 5 of 9
(1,687 Views)

Any reason to not just take the windows X out of the equation?

0 Kudos
Message 6 of 9
(1,684 Views)

That's certainly an option. Currently, my production program, (what I shared was just me playing in my sandbox) has both the 'X' and a 'Stop' button. Pressing Stop provides a controlled shutdown, whereas 'X' ... well you know. 

 

Deleting X would force users to press Stop, if they remembered. Thing is, people are so set in the Windows paradigm that I feel removing X would cause a minor panic. To avoid this I'm going to send the program to it's End case for a controlled shutdown when X is pressed, and probably remove the Stop button instead.

0 Kudos
Message 7 of 9
(1,678 Views)

Pressing [X] is the correct way to stop an application and you can definitely discard it and trigger any required shutdown steps. Every computer user is familiar with the [X], no point for other mechanisms! (See also slide 27+ in my old presentation)

 

Here's a slightly cleaned up version of your code, maybe it can give you some ideas.

 

 

.

Message 8 of 9
(1,665 Views)

That's nice. I'll have to study it a little to be sure I really understand it, but thank you for taking the time to do this.

0 Kudos
Message 9 of 9
(1,654 Views)