The bindings for menubuttons/menus allow mouse
selection by
either press-drag-release or by click-move-click, and
both
normally work fine. However, when the menu is posted
so it
overlaps the menubutton, the click-move-click scheme
fails
because some random menu item receives the
ButtonRelease
from the initial click on the menubutton, and gets
selected
immediately.
I have included a demo, if that is of any use. Try
clicking on
the menu button with the window positioned mear the
bottom
of the computer screen.
This behavior occurs on Linux installations of Tcl 8.0
- 8.4.1
(at least). I suspect the problem does not occur on
Windows.
I think the bindings for menus should not accept a
ButtonRelease
for some short period after the menu is posted. The
short period
is probably specified by the window manager settings as
the
button-click time.
As a work-around, I have been using:
bind Menubutton <Button-1> {+
bind [winfo children %W] <ButtonRelease-1> {break}
after 300 { bind [winfo children %W]
<ButtonRelease-1> {}}
}
to disable the ButtonRelease event in menus for the
first 300ms
after the MenuButton is clicked on.
Logged In: YES
user_id=68433
The attached test case appears to be out-of-date --
following the instructions in the label (move the window to
the bottom of the screen and click on the menubutton), in Tk
8.4.9 the menu is posted above the menubutton, not on top of
it. (The menubutton in effect switches from '-direction
below' to '-direction above' if '-direction below' would
place the menu offscreen).
Don't know if the underlying problem is still present, but
the test case doesn't seem to trigger it anymore.
updated test case
Logged In: YES
user_id=611156
Indeed, the the change of '-direction' goes a long way to
relieving this problem. It makes it much less likely for a
menu to overlay its menubutton and receive the end-of-click
ButtonRelease.
I've modified the test case by adding several dwarves to the
dwarfs menu. Now it should fail when the window is in the
middle of the screen, but succeed when at the top or bottom
(but depending on the screen size).
I do feel that the overlap, by itself, is not wrong, even
though the bug can be fixed by either preventing overlap or
by delaying the bindings. It is the blind acceptance of any
ButtonRelease, even when it is part of the initial short
'click' that is conceptually wrong.