Lock front panel in an event structure

[Sima]

Why is the "Lock front panel until the event case for this event completes" option in an event structure checked by default? I rarely, if ever, seem to leave it checked. In what case would you need it to be checked?

[JÞB]

---

Sima wrote:
Why is the "Lock front panel until the event case for this event completes" option in an event structure checked by default? I rarely, if ever, seem to leave it checked. In what case would you need it to be checked?

---

When you want to prevent other UI generated events to keep the user from taking actions faster than the code processes them.  For example, suppose event A calls a prompt sub vi that passes a new value requred for event B.  certainly it would be wise to prevent the action that causes event B until the new data is ready to operate on.

It might not be ideal that the default is lock but, it sure forces the developer to consider data interactions when constructing the event cases.  IMHO, since events break data flow, defaulting to lock the front panel seems to be the safer route to prevent accidental race conditions since the blockage of user input simulates a pseudo-data flow control paradigm and THAT thought is so ingrained in LabVIEW developers that we hardly even think about it.

[Ben]

---

Sima wrote:
Why ...In what case would you need it to be checked?

---

"Why" question are best answered by those in the room when the decision was made. Not being one of those I will speculate that it si help out the noobs that haven't quite grasped the data flow paradigm and use FP objects to hold the data states.

So lets say the want to record or replay using one of two button and the replay required a lot of time to get started. A user could hit the "replay" but due to the slow start-up the user could think it was stuck and try record. This would put things in both replay and record at the same time. Since multiple events structures are allowed in a VI locking could also help there.

I usually stay with the default of "lock" and make sure all of the event complete faster than they can click.

Just my 2 cents,

Ben

[Sima]

But doesn't the lock front panel event still queue events in the background? This is confusing to me. Please see attached VI. If you click Button 1 and immediately click Button 2 after that, both events take place (Button 1 event then Button 2 event). With this option checked, shouldn't it not respond to any other user events until the current event is completed?

[Ben]

I admit my previous example was contrived to try and guess why lock FP was selected as the default. I will not even try to put together an example to illustrate what I had in mind becasue I feel dirty using the GUI to control my applicaiton state.

Again its not easy to answer "why..." qustions without having been there.

Ben

[Sima]

Hi Ben, that's why I figured I'd drop the "why is it checked by default" question and just try to understand the functionality a bit more. I also agree with you by not relying on the GUI to control program flow. But since you mentioned you use this option... I don't understand why my VI does not stop the user from clicking any other button (or generating any other event) until the first event is done. Isn't this the intended functionality of this option? In my particular VI, the behavior doesn't seem any different whether I check or uncheck it.

[Ben]

---

Sima wrote:

... I don't understand why my VI does not stop the user from clicking any other button (or generating any other event) until the first event is done. Isn't this the intended functionality of this option? In my particular VI, the behavior doesn't seem any different whether I check or uncheck it.

---

Last part first

the behavior doesn't seem any different  

Watch your VI closely using lock and un lock settings on the button 1 event. When it is locked, you can click on button 2 (queueing up an event for the event structure) BUT the image of button 2 does not respond graphically to the button click until the running event completes. The locking applies to GUI updates.

"stop ... generating any other event..." 

I think this code illustrates one method of disableing generating events while an event is running.

 

It uses dynamic events by first registering for the value change on button 2. When button 1 event fires it re-registers the event for a null event thereby shutting down events from button 2. After the delay the button 2 event is re-registered and button 2 can now gen events.

Does any of this help?

Ben

[Sima]

Yes, I noticed that the button status changes with the option unchecked. Unfortunately, I still don't understand the benefit of "The locking applies to GUI updates."  If users can still click on other buttons and, OK, the button doesn't change status, but the event still fires immediately after the first one, then what has that option done for us besides delay the GUI response? What is the benefit of locking the GUI updates? The impression I would get as a user if I click on Button 2 after clicking on Button 1 and see that Button 2 status doesn't change, is that the program is ignoring my clicking of Button 2... only to be surprised with the Button 2 event as soon as Button 1 is done. I thought that what your VI does was what the lock front panel option was meant to do. I think it would be a good option if it didn't actually queue the events and perhaps you could use that to disable firing the same event over and over if the user clicked several times, instead of say disabling the button with a property node or doing what you do in your VI until the event is done.

[aeastet]

I hae always found this strang as well. Is there an easy way to keep events from firing when the system is busy?

[Ravi_Beniwal]

Locking front panel or not doesn't make any difference if you have only one event structure in your VI, because one case has to finish executing before the next one can execute. But it makes all the difference if you have more than one event structures in the VI.

Please see the attached VI. If you click OK 1 with the event locking the front panel, clicking on OK 2 will not wake up event loop 2 to process the corresponding event, even though there is no data dependency between the loops.

On the other hand, if the event for OK 1 doesn't lock the front panel, clicking on OK 2 will execute the corresponding event in loop 2 immediately.