topic Re: Cannot completely disable a dimmed command button in LabWindows/CVI

Cannot completely disable a dimmed command button

dcl9000 — Thu, 13 Jan 2011 02:45:33 GMT

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?

Re: Cannot completely disable a dimmed command button

ISITEC_RIEPER — Thu, 13 Jan 2011 07:24:54 GMT

Hi,

did you try DelayWithEventProcessing instead of ProcessSystemEvents and Delay ?

Greetings from Bremerhaven

Norbert

Re: Cannot completely disable a dimmed command button

Al_S — Thu, 13 Jan 2011 22:13:42 GMT

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/205111

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.

Re: Cannot completely disable a dimmed command button

dcl9000 — Thu, 13 Jan 2011 22:51:13 GMT

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.

Re: Cannot completely disable a dimmed command button

Al_S — Thu, 13 Jan 2011 23:11:10 GMT

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.

Re: Cannot completely disable a dimmed command button

dcl9000 — Thu, 13 Jan 2011 23:27:49 GMT

Thanks, Al!

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

Re: Cannot completely disable a dimmed command button

RobertoBozzolo — Fri, 14 Jan 2011 07:36:06 GMT

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.

Re: Cannot completely disable a dimmed command button

dcl9000 — Fri, 14 Jan 2011 18:25:28 GMT

Thanks, Roberto!

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

Where to call ProcessSystemEvents() is the key.

Re: Cannot completely disable a dimmed command button

LuisG — Mon, 17 Jan 2011 17:35:26 GMT

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

Re: Cannot completely disable a dimmed command button

dcl9000 — Mon, 17 Jan 2011 20:02:15 GMT

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.....

Re: Cannot completely disable a dimmed command button

nickb — Mon, 17 Jan 2011 20:55:42 GMT

A little clarification on that Reported Version field in a Known Issues List...

The Reported Version field doesn't specify when we found out about a bug, but who is affected by the bug. In this case, we actually found the bug only a few months ago. A reported version of 6.0 means that all versions of CVI going back to 6.0 would be susceptible to this bug.

NickB

National Instruments

Re: Cannot completely disable a dimmed command button

dcl9000 — Mon, 17 Jan 2011 23:18:44 GMT

Hi! Nick,

If this issue is fixed in CVI 2010, does it mean SetCtrlVal() can update the LED instantly enough without using ProcessDrawEvent()?

How about this case: http://forums.ni.com/t5/LabWindows-CVI/LED-Indicator/m-p/294514?

Many of us have known this issue since 2005.

Maybe it wasn't correctly reported as a bug...

Re: Cannot completely disable a dimmed command button

nickb — Tue, 18 Jan 2011 14:30:35 GMT

Yes, in CVI 2010 and later, SetCtrlVal will update the status of the LED immediately, as it should have all along. It does look like the forum you mentioned never resulted in an actual bug report, which would explain why we were unaware of the issue until recently.

NickB

National Instruments