Disabled control in event value change still responds

[altenbach]

---

@parthabe wrote:
Can you please repost the VI Disabled_control_in_eventFIXED.vi saved for LV 7.1 ?

---

You can do the fix yourself! It takes faster than downloading a new version. 😉

Simply edit the event for "Numeric IN: value changed" and uncheck the "lock panel" option. Now the events are handled while the control is disabled and thus properly ignored. They are no longer postponed until after the event has finished and the control enabled again.

Message Edited by altenbach on 05-31-2007 08:08 AM

[Deon]

Unfortunately the problem does still occur if the Disabled property node is located outside the event case, which is where I need to use it to prevent an operator from using the function under certain external conditions. To me this is a bug. Btw I'm using v8.5.1

Regards Deon.

[Van_L]

Hi Deon,

I tested the first sample code of this thread on both 8.5 and 8.5.1, it works perfectly fine as stated.

Can you try the same sample code please?

Thank you

[Deon]

Yes, I found the problem. I was using a Mouse Up event instead of a Value Changed event.

Thanks.

[ST5]

I arrived here with a search on Google.

I have the same problem, I use Labview 2009.

A sample program is in Attachment.

When I put a case in the event structure (see event button 3), I have a workaround,

but while having to use cases, why do I use the Event structure after all?

.

[Justin_P]

I don't understand the question.  Could you rephrase it for me.

[ST5]

The button is disabled.

The Event structure executes when the disabled button is clicked.

I don't want that. I disabled the button for not receiving an action when it is clicked.

I did not disable the button for nothing, or just change the color.  

[RavensFan]

No, the event is not fired when the button is clicked.  The mouse down event is fired which has actually nothing to do with "clicking" the button.  If you read the context help for the disabled property, it says "The object appears dimmed on the front panel, and the user cannot operate the object".  Your button is disabled, so when you click on it, the button does not operate.  So a value change event won't fire because the operation of the button is disabled.  Disabled does not block the events of mouse down or mouse up.  There could be a number of reasons why a person may want to detect a mouse down or mouse up on a control that they may not be able to operate.  Perhaps a part of some configuration routine where they want to be able to select a control for the sake of changing its text, or color, or whether it even remains disable, without actually operating the control.

Why are you using the mouse down event instead of the value change event?  If you still need to use the mouse down event but don't want the event to actually do anything in the situation the control is disabled, then wrap your code in a case structure that reads the current status of the button and only execute the code in the event the status is enabled just like you are doing in the event case for button 3.

[ST5]

I'm using "Mouse down" instead of "Value change" because the buttons are "latch on"

The "Value Change" would operate it twice, once on click, one on click release.

So this is no solution.

Thanks for the reply 

[RavensFan]

---

ST5 wrote:

The "Value Change" would operate it twice, once on click, one on click release.

---

What makes you say that?  Have you seen that behavior? 

Latching action does not cause a value change event based on the button popping back up itself when it is read.

Put your buttons in their respective event cases.  Set them for Value change events.  Now when you click a button, the event will fire.  When the event fires, the control terminal will read which will "unlatch" the control.  That unlatching action does not cause another value change event.

Now if you have a latched control that is never actually read, then clicking to set the button will cause a value change event, and clicking again to unset the button would cause a 2nd value change event.

See attached.