Prev: Remote devices send out EOF when running in cron?
Next: Tcl interface to the FrameMaker desktop publishing system
From: Óscar Fuentes on 9 Feb 2010 17:09
Is there a simple mechanism for disabling all keyboard input for a given
toplevel and enabling it later?

Recursively disabling all widgets is too complex (have to remember which
widgets were already disabled, which widgets changed its state while the
keyboard was blocked, etc). I was thinking on creating a hidden toplevel
and put a grab on it, but I'll like to hear some opinions first.
From: Robert Heller on 9 Feb 2010 18:24
At Tue, 09 Feb 2010 23:09:43 +0100 =?utf-8?Q?=C3=93scar_Fuentes?= <ofv(a)wanadoo.es> wrote:

>
> Is there a simple mechanism for disabling all keyboard input for a given
> toplevel and enabling it later?
>
> Recursively disabling all widgets is too complex (have to remember which
> widgets were already disabled, which widgets changed its state while the
> keyboard was blocked, etc). I was thinking on creating a hidden toplevel
> and put a grab on it, but I'll like to hear some opinions first.
>

man grab
man focus

Trick: create a canvas, but never map it. Set grab and focus there
during times that things are 'busy'. Keyboard / mouse events are
flushed away.


--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/

From: Óscar Fuentes on 9 Feb 2010 19:07
Robert Heller <heller(a)deepsoft.com> writes:

>> Is there a simple mechanism for disabling all keyboard input for a given
>> toplevel and enabling it later?
>>
>> Recursively disabling all widgets is too complex (have to remember which
>> widgets were already disabled, which widgets changed its state while the
>> keyboard was blocked, etc). I was thinking on creating a hidden toplevel
>> and put a grab on it, but I'll like to hear some opinions first.
>>
>
> man grab
> man focus
>
> Trick: create a canvas, but never map it. Set grab and focus there
> during times that things are 'busy'. Keyboard / mouse events are
> flushed away.

Thanks for the advice. I've checked that setting the focus on the main
toplevel (which has no problematic keyboard bindings) does the trick,
but what you suggest is more robust.
From: Óscar Fuentes on 10 Feb 2010 09:37
Robert Heller <heller(a)deepsoft.com> writes:

>> Is there a simple mechanism for disabling all keyboard input for a
>> given toplevel and enabling it later?
>
> man grab
> man focus
>
> Trick: create a canvas, but never map it. Set grab and focus there
> during times that things are 'busy'. Keyboard / mouse events are
> flushed away.

It seems that it is not possible to set the focus on an unmapped widget.
From: Robert Heller on 10 Feb 2010 14:40
At Wed, 10 Feb 2010 15:37:08 +0100 =?utf-8?Q?=C3=93scar_Fuentes?= <ofv(a)wanadoo.es> wrote:

>
> Robert Heller <heller(a)deepsoft.com> writes:
>
> >> Is there a simple mechanism for disabling all keyboard input for a
> >> given toplevel and enabling it later?
> >
> > man grab
> > man focus
> >
> > Trick: create a canvas, but never map it. Set grab and focus there
> > during times that things are 'busy'. Keyboard / mouse events are
> > flushed away.
>
> It seems that it is not possible to set the focus on an unmapped widget.
>

Huh? Sure it is -- I do this all of the time. By 'unmapped' what I
mean is creating a widget (such as a canvas, which normally will accept
both keyboard and mouse events) on the same toplevel as you are
displaying and then never packing, placing, or gridding it. I would
normally do this on the toplevel widget, which is generally always
displayed.


--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/

 |  Next  |  Last
Pages: 1 2 3
Prev: Remote devices send out EOF when running in cron?
Next: Tcl interface to the FrameMaker desktop publishing system