Panel Close? Event causes front panel to be unresponsive

[JeffGordon555]

I'm trying to create a simple program. There is a while loop that generates random numbers just so I can see it's running. An "Exit" button is wired to the exit terminal of the while loop. An event structure is also in this while loop, which catches "Panel Close?" and discards it, then wires true to the exit terminal of said while loop. To be more specific, the exit terminal takes an OR statement that takes the Exit button and this Event Structure boolean as inputs. However, when I run the program, the Exit button doesn't respond, though with highlight execution the event structure part of the program seems to be working. Sorry if I'm bad at explaining, any help is appreciated.

I guess my real question is, how do you properly implement that an exit button stops the loop and clicking the red x or File:Close is ignored and instead does the same thing as your Exit button.

[nathand · Accepted solution]

The problem is that you don't have a timeout case in your event structure, so it sits there waiting for any registered event to occur (in your case, the only registered event is the panel close event).  It only reads your Quit button once, as you should see if you run with execution highlighting.  The while loop can't continue until everything inside of it completes, and the event structure can't complete until an event occurs.

A better solution than adding a timeout event is to add a Value Change event for the Quit button.  Put the Quit terminal inside that event case and wire that to the same tunnel that is connected to stop the while loop.  If you do this there's no need for the loop timer since the event structure will sit there waiting until either the Quit button is pressed or the panel is closed.  However, if you're going to add more code inside the while loop that needs to execute continuously, then you will need a timeout event (which can take the place of the Wait since the timeout will regulate the loop timing).

[SteveChandler]

Here is an example of how to do that

[VeeJay]

Thank you for the example. I have a question though. What if inside the event structure (Under time out event case), we have a state machine and inside a few states, there are parallel loops? THnks!

[Peter-E]

What behavior are you seeing with this certain set up in the time out event case? Is the panel close event unresponsive then?

Do you mind posting a VI of what you are referring to so we can get a good understanding?

Thanks!

Peter E

[Mark_Yedinak]

---

@VeeJay wrote:

Thank you for the example. I have a question though. What if inside the event structure (Under time out event case), we have a state machine and inside a few states, there are parallel loops? THnks!

---

This is generally a bad design. The event structure should contain minimal code. Parallel loops within the timeout event sounds like a recipe for disaster. In addition, the whole purpose of using the event structure is to process events when they occur and to avoid polling. What you are describing sounds like polling within the event structure. Overall sounds like a poor design.

[VeeJay]

Hi Mark,

Actually, I have not implemented it yet. I was wondering. My code is a Statemachine. It has certain states and in operational state, there are parallel loops running. Any error in one of the loops signals all loops to STOP and I exit that state. My question was how to implement the panel close? event. I don't want anyone to accidently close the LabVIEW application unless they intend to.

V

[Mark_Yedinak]

For applications that require a user interface I prefer to use a producer/consumer architecture. The producer loop with the event structure essentially does nothing but deal with the UI. It will process UI events as well as provide the ability to update the UI. The consumer loop(s) do the actual work. These loops are generally some form of a state machine but they allow messages to be passed from the producer loop for control purposes. Most common are start, stop and exit events. This type of approach allows your UI to be very responsive to user input. Even though your application may take time to shut down cleanly you can immediately let the user know you are going into shut down mode. They know you receive their input and are working on it. This prevents them from pressing the stop button multiple times. If your shut down does take a very long time make sure you provide regular updates to the user informing them you are still running and not simply hung.

[ni4sshankar]

---

@Mark_Yedinak wrote:

 If your shut down does take a very long time make sure you provide regular updates to the user informing them you are still running and not simply hung.

---

Please help me understand or enlighten me with a sample vi where the shutdown is taking more time and there is enough user updates until the shutdown is complete.

Kindly ignore if this is not a relevant post here.

Thank you for your time to respond