Tk Source Code

View Ticket
Login
Ticket UUID: 1236306
Title: TraverseToMenu error with alt binding to toplevel destroy
Type: Bug Version: obsolete: 8.5a6
Submitter: fvogel Created on: 2005-07-11 20:36:25
Subsystem: 12. Unix Menus Assigned To: fvogel
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2015-07-28 20:36:42
Resolution: Fixed Closed By: fvogel
    Closed on: 2015-07-28 20:36:42
Description:
Consider the following three-line script:

toplevel .t
bind .t <Alt-a> {destroy .t}
bind .t <Alt-b> {after 0 destroy .t}
bind .t <Alt-c> {destroy .t;break}

Pressing Alt-a displays an error message:

bad window path name ".t"
bad window path name ".t"
    while executing
"winfo class $w"
    (procedure "tk::TraverseToMenu" line 6)
    invoked from within
"tk::TraverseToMenu .t a"
    (command bound to event)

while Alt-b or Alt-c does not.

This occurs on Linux, not on Windows, for Alt bindings 
only (not for Control, Shift... bindings).


Analysis of the problem:

% toplevel .t
.t
% bindtags .t
.t Toplevel all
% bind all
<<PrevWindow>> <Key-Tab> <Key-F10> <Alt-Key>
% bind all <Alt-Key>
 tk::TraverseToMenu %W %A

The bindtags are processed in turn. <Alt-a> binding 
for .t is executed first. There is no matching binding for 
Toplevel, but there is a binding for the Alt key for the all 
bindtag. So this one is executed after the toplevel is 
destroyed.

The bug is therefore that tk::TraverseToMenu doesn't 
check that the toplevel still exists.
User Comments: fvogel added on 2015-07-28 20:36:28:
Fixed in trunk and core-8-5-branch (back in 2005 I didn't have commit access, now I can do it myself).

anonymous added on 2015-07-23 22:38:21:
FWIW, this bug is still open, with 8.6.3, even with the same error msg already reported in the original bug report

fvogelnew1 added on 2007-08-29 02:00:21:
Logged In: YES 
user_id=1245417
Originator: YES

Gentlemen,

I still have this bug with Tcl/Tk 8.5a6 and 8.4.15 on Suse 10.1. Exactly the same error message as in my initial report. As said, this is a Linux bug, it does not happen on Windows (don't know for Mac).

Comments below state that it is supposed to be fixed in 8.5a4 and 8.4.13, but I have it in both 8.5a6 and 8.4.15. I reopen. 

Francois

hobbs added on 2006-05-26 01:05:24:
Logged In: YES 
user_id=72656

There was a related bug in requesting the eventPtr before
we'd validated the window.  Fixed in 8.5a4.

hobbs added on 2006-03-31 14:32:21:
Logged In: YES 
user_id=72656

This only seems to affect 8.5 (not 8.4.13), so I've fixed it
by not returning an error when the window isn't found in
WinMenuKey.

fvogelnew1 added on 2006-03-18 20:00:47:
Logged In: YES 
user_id=1245417

Today with the latest HEAD, situation is slightly 
different.

Pressing Alt-a produces:
bad window path name ".t"
bad window path name ".t"
    while executing
"tk::WinMenuKey .t 97"
    (command bound to event)

Therefore not yet fixed, but things changed since my 
initial report on 8.5a3. Especially, we now have:

% bindtags .t
.t Toplevel all
% bind all
<<PrevWindow>> <Key-Tab> <KeyRelease-F10> <Key-F10> <Alt-
KeyRelease> <Alt-Key> <KeyRelease-Alt_R> <Key-Alt_R> 
<KeyRelease-Alt_L> <Key-Alt_L>
% bind all <Alt-Key>
tk::WinMenuKey %W %N

WinMenuKey does apparently not check that the %W still 
exists at the time it is called. Problem is probably now 
in win/tkWinMenu.c

Francois

fvogelnew1 added on 2005-07-12 03:43:52:
Logged In: YES 
user_id=1245417

Proposed simple fix:

In library/menu.tcl, replace line 1002:
    if {[string equal $char ""]} {

by:
    if {[catch {winfo class $w}] || [string equal $char ""]} {