Unexpected effect of Lock Front Panel in Event Structure

[algypug]

I have been using LV intensely for only a short time, although I have dabbled with it many times since its first appearance. The "problem" that I have had may well be the intended behaviour, but it just seems unintuitive to me. I'm writing a small application to take measurements from a USB instrument. I have already written a basic driver for the instrument, which the application calls, and the driver is working as expected. In the application, the user can configure various settings and then click an Execute button to transfer them to the instrument. The click event is handled in an event structure along with other events. Since some of the instrument operations take an appreciable time, the first action that occurs in the click event case is to disable the Execute button using a property node so that further clicks are ignored until the operation completes, at which time the button is re-enabled.

When disabled, the Execute button is grayed out as expected and clicking it has no visual effect. However, it seems that clicks made during the disabled period are still queued and acted upon when the button is re-enabled, causing the operation to be repeated.

It is the solution I have found that seems unintuitive to me. The Lock Front Panel check box was checked (by default) for the click event, and I assumed that this would be the correct setting. However, unchecking the Lock check box actually makes everything worked as expected. Click events occurring during the disabled period are now ignored or discarded. I'm not suggesting that this is a bug, but I'm interested to learn why it happens, if anyone can explain. I have attached a picture of a simplified version of the event case.

[RavensFan]

Can you post a simplified VI that demonstrates what you are seeing?  What you are saying sure doesn't sound like it should be happening that way, but it is kind of hard to figure out why it might be doing that without and example we can poke around in.

[Mark_Yedinak]

I don't see anything particularly wrong with the picture of the code you posted. As Ravens Fan mentioned it would help if you posted a code example.

One other thing you might consider is to use a producer/consumer architecture. The reason I say this is that you stated some of your actions take a fair amount of time. Generally you want the UI to be very responsive to user interaction therefore it is generally a good idea to keep processing to a minimum inside that loop. Longer tasks can be processed in a parallel loop (consumer loop).

[dan_u]

I would say what you see is expected behavior, even though it's a bit complicated.

The "Lock front panel until the event case for this event completes" option will only defer clicks and other things generating events until the current event handler completes. So this means that the click is placed in a queue and only evaluated once the event is finished. At this time, the button is no longer disabled, so an event is generated.

When the "Lock front panel until the event case for this event completes" is not checked, the click is immediately evaluated, but it's happening on a disabled control, so it does not generate an event.

From the LV help:

By default, when an event enters a queue, LabVIEW locks the front panel that contains the object that generated that event. LabVIEW keeps the front panel locked until all Event structures finish handling the event. While the front panel is locked, LabVIEW does not process front panel activity but places those interactions in a buffer and handles them when the front panel is unlocked. 

 Note  If an event case that locks the front panel takes a significant amount of time to execute, consider using the Set Busy function or displaying a dialog box to notify the user that the front panel is locked.  

[algypug]

Thanks to all for your responses. dan_u's explanation makes sense to me. At the time of my original post I didn't realise that the "Lock front panel until the event case for this event completes" option queues events while it is applied. It threw me because the button appeared to be disabled. I also understand the comment about wanting the UI to be responsive, but to be honest, at this time the application is not much more than a test harness for the driver. So, unless you insist, I won't post a vi.

It's nice to know that there are good people here who are willing to offer advice. Thanks again for your help. Cheers!

PS. I should have mentioned that I'm using LV 2010 SP1.

[RavensFan]

I was able to recreate the VI that you did not post so I could see the behavior myself.  (This was tested in LV2010 SP1)

Something does not seem right that a "Locked front panel" with the control disabled was still able to capture value change events.  Yet a front panel that is not locked until event is complete does prevent value change events from being queued up on the disabled control.  Maybe someone has a deeper understanding on why this may be.

Here is a snippet of that VI.

[Darin.K]

With the panel UNLOCKED - the click is immediately processed and the control is Disabled so everything seems normal.

With the panel LOCKED - the click itself (not the ensuing events) is deferred until the panel is unlocked.  By this time, the control has once again been enabled so the click generates another event.

It is the activity which is deferred, not just the processing of the activity.

Edit:  Looks like I did one of those English to English translations of Dan_u's post....

[dan_u]

---

@Darin.K wrote:

Edit:  Looks like I did one of those English to English translations of Dan_u's post....

---

Well, you managed to phrase it in less words and easier to understand, I guess

(English is not my primary language as you might have noticed  )

[RavensFan]

Thanks Darin.  That makes sense to me now.

Basically the state of the control (enabled vs. disabled) at the time the activity is processed  (at the click in the case of unlocked front panel vs. at the end of the currently executing event case in the case the front panel is locked) is what determines whether you the click is happening on an enabled or disabled control.

It's odd because if you do two things you think are correct (lock the front panel, disable the control) you get results the opposite of what you'd naturally expect.  So two rights can make a wrong.

[algypug]

@Ravens Fan: Could you try recreating the application that I haven't finished yet? Infinite kudos would yours!