Event Structure: Does "Lock Front Panel" REALLY make LV blind to front panel activity?

[cochenob]

Is it correct that locking the front panel during an event simply implies that you can only run one event at a time?

I've noticed that if I chance the value of a front panel object that is linked to the structure WHILE another event in that same structure is executing, LabView remembers that I've changed something, and will execute it's event after the current one is finished.

Is there really a way to "freeze" the front panel while an event is running?

[Kenny_K]

You are correct that lock front panel is actually lock front panel until the current event finishes executing.

Try using a property node for whatever button/object you want to disable.  The attached example will allow you to click the start button and then it will disable the start button (so you cant queue more events) until it finishes.

See if this is what you are looking for and let me know if you wanted something different.

The VI is for LV8.

Kenny

[mfitzsimons]

What I have noticed experimentally is that the front panel will lock if you are processing one event and a second event is generated.  The front panel will go completely unresponsive until the event is serviced.  I believe this is LabVIEW's way of preventing too many events from being queued up. 

[cochenob]

I tried this previously, and seemed to come up with the same effect....

If I disable the control....proceed with the guts of the event.....and while that's going on, click the disabled control a few times, while it is trun that nothing changes immediately....once I reable to control LabView seems to know that I tried to want to change the value, and will execute the events accordingly in the next loop cycles.

Normally, I don't think this wouldn't be too annoying....except that I think I may be running into a race condition when updating my cluster of many variables.

I especially run into some wacky behavior during the Timeout call, where, I actually do something to the control cluster, rather than just carry on with the rest of the loop.  Unfortunately, there is no "Lock Front Panel" option with the Timeout condition, making property nodes the only way to go.

Thanks for the advice.

[Kenny_K]

You could also try clearing the queue after you press the start button or whatever button you have.  You could ahve you code execute the "guts" and then clear the queue and that might prevent the extra events from getting trough if there are any.

Kenny

[Chaos]

You can take this as a grain of salt as I have never personally tried this.  About four months ago I was digging through all the VIs just to at least familiarize myself with what each one might be used for and I noted this from the Set Busy VI:

You also can use this VI to disable the mouse on the front panel

[MartyS]

Here's what I've encountered regarding event structures and panel-locking (LV 6.1 and 7.0):

(1) If you check Lock Front Panel for an event, that doesn't truly lock the front panel. As other people have noted, other events can be generated from front-panel controls while your event is running. They're queued while the panel is locked, then fire as soon as the panel is unlocked (i.e. when the event case is finished running).

(2) You have to be careful using the disable-button-via-property-node strategy:

[MartyS]

Here's what I've encountered regarding event structures and panel-locking (LV 6.1 and 7.0):

(1) If you check Lock Front Panel for an event, that doesn't truly lock the front panel. As other people have noted, other events can be generated from front-panel controls while your event is running. They're queued while the panel is locked, then fire as soon as the panel is unlocked (i.e. when the event case is finished running).

(2) You have to be careful using the disable-button-via-property-node strategy: