Disabled control in event value change still responds

[gdul]

See attached VI.  The numeric control still queues events on value change when disabled.  However I found that placing the disable property node (the one on the rigth side of the diagram) out of the event case solve the problem. Unless I am missing something, it should work properly in both cases.  

[altenbach]

Interesting....

It's a bit couterintuitive, but if you edit the event and uncheck "lock front panel until event completes", the problem no longer occurs. 😉

Message Edited by altenbach on 05-25-2007 08:42 AM

[smercurio_fc]

The behaviour you're describing doesn't occur in 8.20. Also, it makes sense for the control to generate a value change event if it's disabled for the user, as one can write to the "Value (Signaling)" property even if it's disabled.

[altenbach]

---

@smercurio_fc wrote:
The behaviour you're describing doesn't occur in 8.20.

---

Hmmm... I tested in 8.2.1 and it still happens! Try to click a few times on the increment button of the control every second or so while it is disabled, Then wait... 🙂 

[smercurio_fc]

Ah, I see what you mean now. I was testing it incorrectly. Indeed it does still happen. Normally, handling of an event should be a "quick" thing, and not something that takes seconds, though I know the example is to illustrate a point. As you indicated, "interesting". I wonder if access to the control is left open since the property nodes are inside the event case, and consequently you can still change the value as if it were still enabled.

One interesting side-effect I noticed is that I was running the test VI in highlight mode, and I'm not sure what I did , but at one point I lost complete control of LabVIEW. It was no longer responding to mouse clicks.

Moral: Don't do it this way.

[altenbach]

I would say it's a bug. Probably some obscure race condition behind the scenes caused locking of the FP by the event. As I mentioned, if the FP is kept unlocked, the problem goes away.

I added it to the monthly bug thread. http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=3736#M3736

[gdul]

Thanks for your replies. I have checked in LabVIEW 8.2 and the fix I mention which works in LabVIEW 7.1 does not in LabVIEW 8.20. See attached VI

Kind of strange

[altenbach]

Use my fix, then: 🙂

[gdul]

Sure I will, thanks

[jpeters]

The way I see this, it is not a bug.

Here is what is happening:

You click on the increment button a value change event happens.

This locks the panel and no other mouse events can be handled until the event case finishes.

The control is disabled, then we wait, then reenabled. The event case finishes.

We then handle the queued mouse events on the now enabled control.  This causes more value change events. 

The solution to uncheck the lock panel option seems to be a reasonable workaround here and is consistent with what I described.

Jeff Peters

LabVIEW R & D