Disabled control in event value change still responds

[jpeters]

Giving it a bit more thought I want to say this also....

It is generally bad practice to do anything in an event case that is going to take a long time, like 5 seconds.  You almost always want your event structure free to run and not bog it down by doing any lenghty work.  Unlocking the panel can cause weird things to happen, for example you could get several value changes before you get a chance to disable the control.

I suggest instead of unlocking the panel for this VI that you use a Producer/Consumer architecture.

Here is a modified version of your VI that demonstrates what I mean.

Jeff Peters

LabVIEW R & D

Message Edited by jpeters on 05-30-2007 11:49 AM

Message Edited by jpeters on 05-30-2007 11:52 AM

[Ben]

I can see a use case for an event firing for a disabled control.

It could be used to display a message saying "Control disabled for non-privleged users! Please log-in to use the control."

Ben

[altenbach]

The behavior is not intuitive, even if there is an explanation.

Why should a click on a disabled control cause a "value change" event? (notice, we are talking about a "value change", not e.g. a "mouse down" event). It should not be possible to manually change the value while a control is disabled. That's the entire purpose of disabling a control! These events should not get queued. Ever.

(Similarly, we can also type a new value while it is disabled, and the newly typed value will not appear until the control is enabled again.)

I agree most will never bump into this behavior during normal use but it seems incorrect.

[jpeters]

Why should a click on a disabled control cause a "value change" event?

I argue that we are not clicking on a disabled control.  LabVIEW cannot handle the mouse event until the event structure finishes.  When it does.. the control is not disabled.

Furthermore, events are not queued on a per control basis.  They are queued on a per panel basis. We don't even know that we clicked on the numeric control until it is enabled again. 

I understand that the current behavior isn't intuitive, but I think that it is the best way it can be done.  If you keep your event structure loop responsive these queuing artifacts won't show up.. which is the point to my second post.

That said, LabVIEW has no way to control how fast events come from the OS, so there most likely will be times that events are queued no matter how fast the event structure runs.  It is important to queue events while an event structure is running so that no events are missed.  They might be important to someone's application. 

In this particular case we want to disregrad them, and you could program that logic if you needed it by using timestamps or other means.  (or better following my example)  If we dumped events instead, the user that needs all the events has no way of getting them.

[gdul]

I agree that I should not perform lengthy work in an event case.  On the other hand, I do not understand your first explanation about mouse event.  The problem I mentioned is in the case of value change event

[jpeters]

Sorry if I wasn't clear.  What I mean is that LabVIEW doesn't process messages from the OS until the panel is unlocked.  This happens when your event case is finished. 

Basically, we get a mouse event from the OS... We noticed that the panel is currently handling an event on the diagram so we put this message into a queue.  When the panel is unlocked we can then start processing the events that were queued up while the event case was busy running.

It doesn't matter what event you are currently handling on the diagram.  If it locks the panel, all processing of messages are postponed until after the event case is finished. 

So in your case, the property node reenabling the control is handled before we handle the additional mouse clicks -- this in turn causes more value change events because they are clicks on a now enabled numeric's increment button.  This is what makes it look like we are firing value change events on a disabled control, but in fact, it is just enabled long enough for LabVIEW to change the controls value.

[parthabe]

Hi gdul,

Can you please repost the Disabled control in events 8.20 fix (working in 7.1 only).vi saved for LV 7.1 ?

I wish to see the working of it.

[parthabe]

---

altenbach wrote:
Use my fix, then.

---

Hi Altenbach,

Can you please repost the VI Disabled_control_in_eventFIXED.vi saved for LV 7.1 ?

[gdul]

Thank you for this explanation. It is clear for me now.

[gdul]

Here it is. It works in 7.1 but not in 8.20