Block all keyboard input for a toplevel.
in [TCL]
|
Prev: Remote devices send out EOF when running in cron?
Next: Tcl interface to the FrameMaker desktop publishing system
From: Robert Heller on 11 Feb 2010 07:49 At Thu, 11 Feb 2010 03:14:54 +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? > >> > >> I did > >> > >> if { ! [winfo exists .toplevel.sucker] } { > >> canvas .toplevel.sucker > >> } > >> focus .toplevel.sucker > >> grab .toplevel.sucker > >> <do-something> > >> puts [focus] > >> grab release .toplevel.sucker > >> > >> This prints nothing and the keypresses made while <do-something> are > >> cached and processed normally after the grab is released. > > > > What you have should work. *Depending* on what <do-something> is. > > Generally in my code, <do-something> is usually a tkwait of some sort > > (depends on what is going on). For example: > > [snip] > > > My guess is that your <do-something> is NOT causing the event-loop to be > > reentered. If the event-loop is not re-entered, then the events will be > > neither discarded nor processed. They will just accumulate until the > > event-loop is reentered, probably after the grab has been released. > > Good point but, if that were all of the history, doing > > update > grab release .toplevel.sucker > > would take care of the pending keypresses. Putting the grab as early as > possible and releasing it as late as possible makes things better, but > the problem still happens if you press keys fast enough (I measured the > time elapsed for a fast two-key sequence: it is easy to get less than 20 > milliseconds). The sequence, as shown on the console with the help of > some `puts', is: > > grab > start processing first key event > process second key event > finish processing first key event > ungrab > > Now, I don't know enough about tk's event loop, but AFAIK this shouldn't > happen. Even if some library call on the middle executes an `update', > this shouldn't be a problem since there is a grab. I confirmed that, at > the ungrab point, the current grab is the right one. Question: What platform are you on? If MS-Windows, are you using the console? I *know* that the grab trick I use works perfectly and correctly under Linux. -- 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/ |