#1402 menubutton scripts are confused about their owning menu

[Vince Darley]

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)

[Vince Darley]

Logged In: YES
user_id=32170

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

[Vince Darley]

script to illustrate bug

[Vince Darley]

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.

[Todd Helfter]

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.