in reply to Re: better control of Tk::Button
in thread better control of Tk::Button

One problem with doing the disable alone is that it does not completely prevent multiple click events from occurring. If the app is busy, a second click could be done before the first click is handled and the button is disabled. Scripts such as Autohotkey for windows can also send the events despite the disabled-ness of the button.

The better way to go about this, is to check whether there is already a listBrowse widget in existence. If one already exists, you can destroy the old one and replace it, or skip the creation of a new one, whichever makes the most sense.

As for storing the flag as in the OP's original plan, all you should need is a variable that is scoped to cover the right region:

... { # Extra scope to keep $menuPopped contained to just this region. my $menuPopped = 0; sub thatReadsFlag { ... if ($menuPopped) {} ... } sub thatWritesFlag { ... $menuPopped = shift; ... } } ...

Replies are listed 'Best First'.
Re^3: better control of Tk::Button
by lamprecht (Friar) on Oct 07, 2009 at 18:17 UTC

    'One problem with doing the disable alone is that it does not completely prevent multiple click events from occurring. If the app is busy, a second click could be done before the first click is handled and the button is disabled.'

    I could have sworn, that this second click would be discarded by the Button instance, unless you insert an update() call in between the listBrowse() call and the setting of disabled state. And I'm still sure that this is true for Button-Click events. However there is a bug in Tk::Buttons implementation of the '<Return>' event handler Invoke() (note the capitalization) which can lead to a race condition where -state is not handled correctly in case of multiple '<Return'> events in the queue.
    So +++ to your reply.


    Cheers Christoph

    update: https://rt.cpan.org/Ticket/Display.html?id=50330