Labview events and disabled controls on a tab control

[Philip McDermott]

I have found a wired one.

Run the attached VI. A message popup will appear on screen whenever a mouse up event happens on Boolean. This event happens whether the control is disabled or not.

Now drop the Boolean on the tab control. The event works when the control is enabled but not when its disabled. Bazaar and tragically this is critical to my system

Will NI be doing anything to fix this in a future patch as for now I can't see any work around apart from not to use tab controls which isn't an option.

Help please

Phil

[Labviewguru]

Phil,

Two suggestions:

The first is to contact NI support at ni.com/ask and start a support request. NI may offer a solution, or a workaround. They may not be aware of this problem.

Second, work around the problem. I know you don't want to hear it, but if you can't make it work, you will have to work around it. Try an alternative to using the event. There will probable be a performance difference, but considering that using events DOESN'T perform, and polling will, the answer is clear which method to use.

Good luck, and please keep this post updated with your progress. There's nothing worse than looking for the answer to a problem and finding that someone else had the same problem, only to see that the solution was never posted.

-Mike Du'
Lyea

[PhilippeG]

Here is a quick workaround your button problem.
It work well on rectangular button with no labels as it is (with a little more tweaking you could adapt it on other buttons).
If you have more than one button on your tab, you might want to consider inserting your event structure inside a state machine. You could name the event structure state "read buttons" and when you get to the disable state of your buttons event test, you could treat all the conditions in the event structure and wire the output to call a state (it will also allow you to recall any state without user input on your buttons if you need it). See attached Screen Capture for one button check.

Regards

PJM

[VIGuy]

Interesting. . . Aren't all VIs wired?

Forgive that.

My take is that the disabled boolean on the plain panel is in error and not the one on the tab. If I recall, the Windows defintion of "disabled" is unable to recieve the input focus, and then one would suppose it is also unable generate focus related events.

If you want the event from a disable control, I would suggest the ol' "transparent boolean on top of the "Control" which is actually an indicator" trick.

See attached VI.

[Philip McDermott]

Hi Mike

I'm just worried by the comments made by Ray K on a question from Robert Stephen (link Below)
http://64.4.18.250/cgi-bin/linkrd?_lang=EN&lah=86356c6e8594fa3a10936df5c6631230&lat=1033028776&hm___action=http%3a%2f%2fexchange%2eni%2ecom%2fservlet%2fRedirect%3fid%3d8509179

Looks like there removing all events for disabled controls. I don't know whether you've done polling for a control but it involves programming through the WIN 32 SDK and monitoring the mouse position. Massive pain to do and have done it one time too many. It easier to make NI do the change and remove the problem.

[SachaE]

Nice workaround, but a little on the messy side when you consider an application would then need the transparency over the top of EVERY control that could get disabled - not nice, and tracking their existence then becomes a problem 'cos you can't see them!

I agree that the windows definition of "disabled" is "it is unable to receive the input focus", but that doesn't necessarily mean unable to react to input (depends on the definition of "focus" here. Pedantic, but true)

Let's take a step back and look at the solution methodology. Is it easier to check for a disabled state when using, say the mouse up event, or is it easier to come up with a whole new programming methodology creating new controls, or using the windows SDK.

Personally, I liked the ide
a that a disabled control could generate an event on the mouse up/down so you could allow users the ability to logon to a system to gain the extra functionality (such as coupling with DSC's user handling which can automatically enable / disable controls) or even simply popup a message to say - you don't have access. As long as you know about it doing this, it's easy to handle for.

Please don't take the tools away that make life easier.

S.

[SachaE]

btw, whilst we're on the topic of disabled controls, try setting a latch when pressed boolean control to disabled and true (default false) on a panel, and run the .vi. When the control is read, it pops up - now if you're being strict on the whole disabled thing, the control now has focus of the program! Again - easy to handle for, as it may be that the user pressed the button as it went disabled. It might be critical - you can do things like an Event Val Changed, and ignore it if disabled, but if this was removed, how would you catch the fact it had been pressed at all?

Just my 2 cents worth.

S.

[VIGuy]

Yah, I know its messy, but you didnt mention you needed to this to many controls.

Also, why are you encouraging users to click on disabled items and to expect a reaction? Generally you want to keep the interface to your app consistant with the standard interfaces for your OS. Many would consider what you are trying to do as a "bad practice".

Maybe you have a compelling reason to do so, but with the hint you want to instill this behaviour on many controls sounds as if you don't. In my experience you will have fewer problems with your end users if you stay away from exotic or counter intuative user interfaces. Exception being if the majority of your users are in Berkley.

[Jeremy Braden]

I could not resist not joining the discussion. The reason for the strange behavior is that even though the button is disabled, it still gets mouse events from Windows. Rather than limiting the event structure to just enabled buttons, the designers opted to allow the programmer to discard the event if desired. This gives the programmer the greatest number of options in coding. Who knows? You might want to re-enable a button with an event.

I recommend using the filter data field discard terminal (it is a mouthful of a name). It is that thing on the right side of the event structure. The idea is that if some conditions are met, the actions of the whole event can be discarded at once. I modified the original example with one property node and
a not equal to zero function to get the disabled event feel for the disabled button.

Jeremy Braden
National Instruments

[Labviewguru]

First, couldn't access the link....

Polling a button in LabVIEW is quite simple. You just wait in a loop (with a reasonable delay, I use 250ms standard) for the output of the button, and connect the logic to the loop control. I'm not sure what you mean by having to do this through WinAPI.

I was merely suggesting that you replace the event that looked for a button to be pressed, with a simple polling technique, such as would have to be done if events were not available.