Unless you have a message pump in run there is no need to disable/enable the button. If you don't know what a message pump is very likely you don't have one.
If you still think you need to disable the button show us a complete sample app that demonstrates the issue you are having because disabling the button most likely is not the fix to your actual problem.
Perl's payment curve coincides with its learning curve.
| [reply] |
It usually is more complex than this, as to when you want the normal state returned,
but here are the commands.
sub run {
#disable $push
$button->configure(-state=>'disabled');
#do something
#enable $push
$button->configure(-state=>'normal');
}
| [reply]
[d/l] |
I've tried this, but I'm not sure how to pass $push to the subroutine; specifically in the same statement in which it is being defined. I'm new to local variable usage.
-honyok
| [reply] |
Yeah, it can get tricky. One option is to create the button first, without a command, then after creation, configure it to contain a command, with it's name as a parameter. However, it is probably easiest to use the caller method. This will restore the button after 2 seconds.
#!/usr/bin/perl
use warnings;
use strict;
use Tk;
my $mw = tkinit;
my $push= $mw->Button(-text => "test ",
-command =>[\&save_parms,$mw,'somedata']
)->pack();
MainLoop;
sub save_parms {
print "@_\n";
my $caller = $Tk::widget;
#disable $push
$caller->configure(-state=>'disabled');
#do something
my $timer = $mw->after(2000,sub{
$caller->configure(-state=>'normal');
#enable $push
});
}
| [reply]
[d/l] |