Cannot completely disable a dimmed command button

[dcl9000]

Hi! Everyone,

I thought this topic was solved before, but it comes back to me again.

Please take a look at the code in the attached project.

If the call of "Delay(5)" is placed after "ProcessSystemEvents()" call in the A_Callback() function, B-LED always light up no matter what!? 

Dimming or making button B invisible doesn't disable the command button at all. 

Only when I place the "Delay(5)" call in front of the "ProcessSystemEvents()", the B button will be disabled.

Just by dimming button B, without "ProcessDrawEvents()" and "ProcessSystemEvents()", won't guarantee the button is disabled.

I'm puzzled.  What is the correct way of completely disable a command button?

Does this problem only happen in CVI 6.0?

[ISITEC_RIEPER]

Hi,

did you try DelayWithEventProcessing instead of ProcessSystemEvents and Delay ?

Greetings from Bremerhaven

Norbert

[Al_S]

dcl9000:

The discussion where you got my original example has some discussion on the reason B appears active even when it's dimmed.  If the button is undimmed before the event is processed, then CVI will act on the event.  The reason for calling ProcessSystemEvents is to process the event while the button is dimmed.  Then you won't see the click on B or the light.

Here's the original discussion: http://forums.ni.com/t5/LabWindows-CVI/Dimmed-buttons-delay-but-do-not-disable-a-button-click/m-p/20...

The reason the position of the Delay is important in your modified example is that if you delay after ProcessSystemEvents, you are clicking after ProcessSystemEvents, so your click wasn't handled by ProcessSystemEvents.  You just can't click fast enough to get the click in before events are processed.  So, then again, you're back to the click event not being processed until after the control is undimmed.

This behavior is not peculiar to CVI 6.0.  That's the way CVI processes events.

[dcl9000]

Thanks!

------------
Norbert,
I couldn't find "DelayWithEventProcessing" in CVI 6.0.

------------
Al,

Can we conclude that the call to "ProcessSystemEvents()" is always needed before un-dimming a button if one wants to temporarily "completely disable" a button by dimming it?

Besides dimming a button, is there other way to temporarily "completely disable" a control (button, switch, ... etc.)?  What I mean by "completely disable" is that there is no event generated whatever you do to the "disabled" control item.

[Al_S · Accepted solution]

Whether or not you need to call ProcessSystemEvents to ignore clicks on a button depends on what you are doing at the time and when you will undim the control.  The original question came up when the button was being dimmed and undimmed in a callback.

CVI defers processing of events while you are in a callback.  If you're not currently in a callback, a click event will be processed when it occurs.  If the control is dimmed when that click occurs, (again, outside of a callback), the event will be processed and ignored and you don't need ProcessSystemEvents.

Or if you dim the control from within a callback, then click on the control, then exit the callback without undimming the control, the event will be processed with the control dimmed and will therefore be ignored (without needing ProcessSystemEvents).

So the big question is when will you undim the control?  If you undim it at the end of a long callback, then you need to call ProcessSystemEvents.

But if, for example, you open a panel with a control dimmed, and then undim it after some other event, you don't need ProcessSystemEvents to ignore the click.

Let's say you have a panel with a control for the user to select a filename, and a button to print the selected file.  You don't want Print to be active until the file is selected, so it's dimmed initially by default.  In a callback for the filename control, after the user selects a file, you can then undim the Print button without needing to call ProcessSystemEvents.  Any click on the previously dimmed Print button will have already been ignored.

[dcl9000]

Thanks, Al!

What about my second question?  Any other way to temporarily "completely disable" a control?

[RobertoBozzolo]

Which events are you concerned with? Consider that even decoration generate some events (e.g. left and right clic events)! In this respect, your request to 'completely disable' a control cannot have a unique solution. Commit events are generated only when the control is in HOT mode, while other events have a wider extension.

One possible solution is to add some lines at the beginning of control callback and test the control state: if you have used SetInputMode to dim the control you may test ATTR_CTRL_DIMMED attribute; if you have set ATTR_CTRL_MODE to VAL_INDICATOR you may want to test the same attribute. In either case, when dimmed or indicator you may simply exit the function ant that's all.

This provided you have already implemented Al suggestions on ProcessSystemEvents and so that address a large set of conditions without further coding.

[dcl9000]

Thanks, Roberto!

I agree.  There's no unique solution to "completely disable" a control. 

Where to call ProcessSystemEvents() is the key.

[LuisG]

Hello dcl9000,

Al and Roberto have already explained the need for the ProcessSystemEvents call while the button is dimmed. I just want to take the opportunity to also address the need for the ProcessDrawEvent call after you dim the buttons, since you have comments in your code indicating that you weren't expecting to have to call this function.

For performance reasons, any attribute that you set in the CVI user interface is not reflected in the UI immediately. It will be reflected once you exit the callback functions. This allows you to serialize multiple attribute change operations without the UI having to be refreshed each time. If you would like any attribute change to be reflected immediately, you have to call ProcessDrawEvents (or ProcessSystemEvents), explicity.

In your code comments, you mention that the LED will also not light up if you don't call ProcessDrawEvents. This, on the other hand, is unexpected behavior given that you use SetCtrlVal to light up the LED and not SetCtrlAttribute. Unlike attribute changes, value changes are expected to be reflected immediately in the UI. However, there was a bug in CVI (see bug 231945 in the CVI known-issues list) that caused value changes in an LED control to not draw immediately. Since you're using CVI 6.0, it's therefore not surprising that you're seeing this behavior.

Luis

[dcl9000]

Hi! Luis,

Thanks for your explanation and time to read my comment in the code.

I saw this bug had been reported in CVI 6.0 and not resolved until the 2010 version. 

Can't believe this LED issue took NI almost 10 years to debug.....