Tk Source Code

The attached script shows a bug in the menubutton 
scripts, when the act of creating a menu takes 
some time, and the user inadvertently moves the 
mouse onto a different menu button. Tk tries to 
*post* the menu for the other menubutton, but that 
doesn't exist!

Given we are in the middle of executing bindings 
for the first button, there is no reason for Tk to try 
to do something on the other.

# Now click on menu 'one', but while you 
# are waiting for it to popup, move the 
# mouse over menu 'two'.  
# 
# You will get the following bgerror:
# 
# invalid command name ".two.m"
#     while executing
# "$menu cget -type"
#     (procedure "MbPost" line 13)
#     invoked from within
# "MbPost $new $rootx $rooty"
#     (procedure "tk::MbMotion" line 14)
#     invoked from within
# "tk::MbMotion .one down 95 93
# "
#     (command bound to event)

Serhiy, many thanks for fixing this very long-standing bug! Merged into main, core-9.0-branch, and core-8-6-branch by commits [7dc6185f], [471d607b], and [81890c07].

Still present in 8.6 and 9.1: a click on a menubutton whose menu does not exist yet raises "invalid command name" and "bad window path name" errors, and with the attached script the pointer motion to the other menubutton during the binding script posts the menu of that one (an error if it does not exist yet). The scenario of the script (an event loop in a <Button-1> binding of the menubutton) is quite uncommon; the usual way to create the menu on demand is -postcommand. I am not sure that it is worth even such a simple fix. Anyway, it is on branch menubutton-motion-unposted in [ef1ac0348f]: tk::MbPost does nothing if the menu does not exist, like the widget itself, and the pointer motion to another menubutton is ignored unless a menu is posted.

Logged In: YES 
user_id=92123

I have confirmed this bug in 8.4,  Interestingly 8.5a0 has a
different (still buggy) behavior, which I will attempt to
describe. 

First click on menu 'one' then move the mouse over menu
'two'.  Instead of the bgerror of invalid command, menu
'two' will post a menu instead of menu 'one'.

It appears that a race condition is introduced by multiple
bindings.

Logged In: YES 
user_id=32170

NB.  Even if I try to workaround the problem, by putting 
a 'grab' on the menu while the long process is taking 
place, then the error moves to, say, the button-up 
binding on the other menubutton.

File Added - 41578: menuButtonTest.tcl

Logged In: YES 
user_id=32170

Attaching file -- why doesn't sourceforge ever do this 
on first try?