LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Can you debounce panel buttons?

I have an application that uses several panels, displayed on top of each other. Each panel has buttons.
As an example, let's say that panel A has an exit button. Panel B is displayed on top of panel A and it also has an exit button in relatively the same position.
 
The users are complaining that if they inadvertantly double-click, it exits panel B and exits panel A. They only intended to exit panel B.
 
Is there a way to easily debounce the button presses?
 
Thanks!
DJW
0 Kudos
Message 1 of 12
(4,184 Views)

I see no easy solution to your problem: it's difficult to understand when the user double-clicks inadvertedly or on purpose. Supposing you can detect this situation, you could discard the click event on the button by returning 1 to the function, or you could simply rise a flag that instructs button callback to exit without doing nothing.

In situations like this I usually prompt a confirmation message with PromptPopup so that the user is required for an explicit confirmation of this action.



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
0 Kudos
Message 2 of 12
(4,175 Views)
Why not just dial up (or down)  the time allowed between clicks that are considered a "double click" ?  You can do this with mouse settings from the control panel on Windows machines.

Menchar
0 Kudos
Message 3 of 12
(4,170 Views)

Thanks for the suggestions, however, neither of them are options for me. This is a widely distributed program so I don't have control over the mouse functions. And it's been around awhile so I don't have the liberty of adding the confirmation popup. I guess I will try disabling the buttons within the event call back.

DJW

0 Kudos
Message 4 of 12
(4,164 Views)
One rather straightforward solution would be to size the panels (or move the buttons) in such a way that the buttons did not overlap.  I realize that if you have a standardized layout, this may not be possible.  Another option would be to respond to the panel's EVENT_GOT_FOCUS event by setting a global flag that indicates your button should be disabled. Immediately after setting the flag, you can enable a timer (maybe .2 sec) whose callback does nothing but clear the flag and disable the timer.  This means that for a period of .2 seconds after your panel becomes active, the flag is set.  Your button callback now just needs to ignore EVENT_COMMIT (or better yet, swallow EVENT_LEFT_CLICK) when the flag is set.  Admittedly, this is more complicated than desirable, but the timing of the scenario makes it the only good solution I can think of.

Mert A.
National Instruments

0 Kudos
Message 5 of 12
(4,141 Views)
Something like that should do the trick (tested with an InstallPopup'ed panelB :
It's not really something I'm proud of...



int CVICALLBACK QuitBCallback (int panel, int control, int event,
        void *callbackData, int eventData1, int eventData2)
{
int Status;
int panelGUE;
int ctrlGUE;
int ActivePanel;

    switch (event)
        {
        case EVENT_COMMIT:
            DebugPrintf("QuitBCallback COMMIT\n");
            Delay(0.100);
            do
                {
                Status = GetUserEvent(0, &panelGUE, &ctrlGUE);
                }
            while (Status != 0);
            
            ActivePanel = GetActivePanel ();
            if (ActivePanel == panelB)
                {
                RemovePopup(panelB);
                }
            break;
        }
    return 0;
}


Best regards,
Nicolas
0 Kudos
Message 6 of 12
(4,122 Views)
The do/ while loop may be replaced by a ProcessSystemEvents.
The idea is to allow another event to fire while processing the first EVENT_COMMIT.
if (ActivePanel == panelB) is there to avoid removing panelB a second time.

Best regards,
Nicolas



0 Kudos
Message 7 of 12
(4,116 Views)
It's true that there are people who after 10 years of computer usage still
cannot grasp to difference between a left click and a right click, so a
single/double click may be completely out of their reach. But personally I'd
let the problem solve itself. Maybe after they crash the program 60 or 70
times, they'll figure out the difference.
Otherwise, why do you care if they use the program at all ?!?

OK, call my an cynical elitist...
--
Guillaume Dargaud
http://www.gdargaud.net/
"Smith & Wesson - the original point and click interface."


0 Kudos
Message 8 of 12
(4,069 Views)

To cynical - My users are U.S. soldiers. It is my job and my civic responsibility to support them in any way I can.

To Mert and Nicolas- Thanks for the ideas. I understand both of your implementations and will give them a try.

 

DJW

0 Kudos
Message 9 of 12
(4,061 Views)
> To cynical - My users are U.S. soldiers. It is my job and my civic
> responsibility
> to support them in any way I can.

Then it gets frightening !!!

BTW: I wasn't serious, but I didn't have any simple fix to offer...
--
Guillaume Dargaud
http://www.gdargaud.net/


0 Kudos
Message 10 of 12
(4,018 Views)