Bug in BWidget or Tk
Frank Pilhofer
Hi Folks,
has anybody ever seen this problem? When invoking a BWidget menu item
through an accelerator key, then I get the following error if and only
if the "main" window is obscured by another window if the event loop is
entered again:
bad window path name ""
while executing
"winfo toplevel [focus"
(procedure "tkMenuFind" line 8)
invoked from within
"tkMenuFind [winfo toplevel $w] $char"
(procedure "tkTraverseToMenu" line 15)
invoked from within
"tkTraverseToMenu . o"
(command bound to event)
Everything works fine if the menu item is invoked through the menu (using
the mouse). Also, everything works fine if the main window is not obscured
(by a Tk or foreign window) while processing the command.
The following script demonstrates this problem. If the File->Open command
is invoked through the menu, all is fine. But if you press the accelerator
Alt-o, you should get the above error after closing the new window.
The problem persists on Linux with BWidget 1.3.1 and Tk 8.3.4.
I'd like to file it with sourceforge, but haven't traced yet whether this
is a bug in Tk or BWidget.
Frank
package require Tk
package require BWidget
proc FileOpen {} {
set top [toplevel .top]
wm title $top "Hello World"
set but [button $top.but -text "Close" -command "set ::mutex 1"]
pack $but -padx 100 -pady 100
grab set $top
vwait ::mutex
grab release $top
destroy $top
}
set menudesc {
"&File" "" "" 0 {
{command "&Open" {} "" {Alt o} -command FileOpen}
{command "&Exit" {} "" {Alt x} -command "exit"}
}
}
set mainframe [MainFrame .mainframe -menu $menudesc]
set frame [$mainframe getframe]
label $frame.dummy -text "Press Alt-O"
pack $frame.dummy -fill both -expand yes -padx 200 -pady 200
pack $mainframe -fill both -expand yes
vwait forever
--
Frank Pilhofer ........................................... f...@fpx.de
Life would be a very great deal less weird without you. -Douglas Adams
Harald Oehlmann
I think this is a bug in Tk.
If you press the ALT-key the menu tries to find an entry with the
corresponding letter. This does aparently not work if the application does
not have the focus, which is aparently the case in this transient moment.
You can:
- use accelerator without "ALT" (for example CTRL-o) to avoid this problem.
I don't understand the tk code but the function tkMenuFind should only be
invoked if the application has the focus (e.g. [focus] != "").
So you can patch it in the tk8.3/menu.tcl file
or do the following hotfix:
rename tkMenuFind tkMenuFind2
proc tkMenuFind {w char} {
if {0 != [string length [focus]]} {
return [tkMenuFind2 $w $char]
} else {
return ""
}
}
I would suggest to submit a bug report.
I hope this helps,
Harald
(Harald....@Elmicron.de auch auf Deutsch)
--- von Frank Pilhofer (f...@fpx.de) am Donnerstag, 14. März 2002 12:06---
Bruce Hartweg
"Harald Oehlmann" <Harald....@ELmicron.de> wrote in message news:jqkq6a...@elmicron.de...
> Dear Frank,
>
> I think this is a bug in Tk.
>
> If you press the ALT-key the menu tries to find an entry with the
> corresponding letter. This does aparently not work if the application does
> not have the focus, which is aparently the case in this transient moment.
>
If the app doesn't have focus, how did it get the ALT key event in the first place?
what platform do you see this on? I have seen problems on UNIX platforms as
a menubar menu actually creates a clone and the menuProcs are working with the wrong
widget.
Bruce
joe_english
>"Harald Oehlmann" wrote:
>>
>> I think this is a bug in Tk.
Agreed -- see below.
>>
>> If you press the ALT-key the menu tries to find an entry with the
>> corresponding letter. This does aparently not work if the application does
>> not have the focus, which is aparently the case in this transient moment.
>>
>
>If the app doesn't have focus, how did it get the ALT key event in the
>first place?
Here's what's happening:
User presses <Alt-Key-o>
BWidgets has bound <Alt-Key-o> to [$menu invoke $n], where $menu
is the "&File" menu and $n is the "Open..." entry.
This evaluates the entry's -command, in this case FileOpen
FileOpen creates a new dialog with a global grab,
then calls [vwait ::mutex]
User presses the 'Close' button, which sets ::mutex
FileOpen returns from the vwait, releases the grab,
and destroys the dialog
Remember, we're still processing the <Alt-Key-o> binding on "."
[$menu invoke $n] returns.
Now, Tk's binding for <Alt-KeyPress> fires:
bind all <Alt-KeyPress> { tk::TraverseToMenu %W %A }
(This is from when the user pressed Alt-Key-o many steps ago)
tkTraverseToMenu calls [tk::MenuFind "." "o"]
tk::MenuFind executes this loop:
| set windowlist [winfo child $w]
| foreach child $windowlist {
| # Don't descend into other toplevels.
| if {[string compare [winfo toplevel [focus]] [winfo toplevel $child]]} {
>>>--------------------^^^^^^^^^^^^^^^^^^^^^^^^
| continue
| }
I believe the undersharkfinned part is a bug. It should
be [winfo toplevel $w], not [winfo toplevel [focus]].
Under most circumstances, [winfo toplevel [focus]] will
be the same as [winfo toplevel $w] when this code path
is executed. But in Frank's test case, because of a [vwait]
call indirectly invoked by a keyboard binding, the focus
widget gets lost between the time the key is pressed and
[tkMenuFind] gets called.
--Joe English
jenglish at flightlab dot com
Don Porter
> User presses <Alt-Key-o>
...
> FileOpen creates a new dialog with a global grab,
> then calls [vwait ::mutex]
Isn't that the real problem? Re-entering the event loop within an
event binding sounds like a real bad idea to me.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
joe_english
>Joe English wrote:
>> User presses <Alt-Key-o>
>...
>> FileOpen creates a new dialog with a global grab,
>> then calls [vwait ::mutex]
>
>Isn't that the real problem? Re-entering the event loop within an
>event binding sounds like a real bad idea to me.
>
Yeah, that too :-)
But I still think tk::MenuFind is incorrect. Arguably,
so is BWidget for not "break"ing in the menu accelerator
bindings. These three bugs, relatively harmless by
themselves, conspire to cause the problem.
--Joe English
Frank Pilhofer
> Joe English wrote:
> > User presses <Alt-Key-o>
> ...
> > FileOpen creates a new dialog with a global grab,
> > then calls [vwait ::mutex]
>
> Isn't that the real problem? Re-entering the event loop within an
> event binding sounds like a real bad idea to me.
>
I think you'll find that hard to avoid. Popping up a modal dialog from
within a menu item is happening frequently, isn't it? Okay - you could
also avoid `vwaiting' in FileOpen, but return to the main event loop,
and make the button of the modal dialog call another method. But that's
IMHO more complicated, because you need to store all intermediate values
in common variables.
In my original case, the problem was happening even less obviously;
the command handler was a lengthy procedure that frequently called "up-
date" to update the message in the status bar; and it took such a long
time that I switched to other windows (e.g. the editor) to do something
differently inbetween.
But thanks to your analysis, I found a solution that works for me even
without modifying Tk; in the menu binding, I do not invoke the command
right away. Instead of "-command FileOpen", I now do
-command "after 0 FileOpen"
This works around the problem by letting all bindings do their job
first.
I have posted the problem along with Joe's excellent analysis as
Tk bug # 530212.
Thanks,
Frank
--
Frank Pilhofer ........................................... f...@fpx.de
Adolescence is that period in a child's life when parents become
most difficult! - Alfred E. Neuman