Tk Source Code

Greetings,

the Win32 menu keyboard traversal is broken in the
following way:
When a menu (from a menubutton) is posted via the
<Alt-Key> binding (_not_ via the mouse!), the <Escape>
key closes the menu but leaves the menubutton armed.
Unfortunately, another <Alt-Key> on the same menu
then fails! One has to open a different menu before
being able to open the first menu again.

The proposed fix from
http://groups.google.com/groups/search?as_q=Windows+Menu+Keyboard&as_epq=&as_oq=&as_eq=&num=10&scoring=&lr=&as_sitesearch=&as_ugroup=comp.lang.tcl&as_usubject=&as_uauthors=&safe=off

which boils down to adding the line
MenuUnpost {}
to the proc
::tk::MenuFirstEntry
fixes this problem for me.

kind regards,
Randolf
-- 
http://www.ayam3d.org/  NURBS modelling for the masses.

Thanks. The test is added by commit:

• [f72af578] in the main branch
• [6ac0a294] in the core-9-0-branch

Yes. win-alt-key-menubutton only added tests for the internal function tk::TraverseToMenu, and the ones which post a menu are only for X11. menubutton-11.1 tests this bug at the high level on Windows: it simulates pressing F10 and Escape twice and checks that the menu is posted twice. It uses the test command testsendinput, which simulates keyboard input and could be used in other tests.

Does it make sense to merge the new test here to the main branch?

Thanks, Harald

Fixed by commit [ee3cc6ac] within ticket [2128087].

Bug closed.

Thanks for all, Harald

You are right, it has the same cause as [2128087]: on Windows the menu of a menubutton is native, so MbPost returns only after the menu is closed, and the menubutton stayed posted. The fix in branch win-alt-key-menubutton [d6f980fca7] unposts it in MbPost itself, so it fixes this bug too; that is why Escape now unarms the menubutton. My earlier branch bug-2225507 fixed the same thing in a different place and is not needed after that merge.

I think, this is related to bug [2128087].

I used the test case from there. Anyway, I could not invoke the menu by Alt+F or F10 without the patch in that bug.

Pressing "ESC" to close the menu correctly unarms (e.g. removes raised state) from the menubutton.

This was part of the last commit. Nevertheless, the fix is very different.

So, I am doing something fundamentally wrong I suppose.

No good thinking, sorry.

Take care, Harald

Added test menubutton-11.1 in [6339b68a60]: F10, Escape, F10, Escape are injected with the new test command testsendinput (win/tkWinTest.c, uses SendInput()); the menu must be posted twice and the menubutton must be unposted at the end. Before the fix the menu is posted only once. All keystrokes are queued before the first F10 because the native menu blocks the event loop until Escape dismisses it.

The same command is added on the branches for [52e9b0f52c], [a9bd2ab98b] and [f492c3de04]. Merging them will conflict in win/tkWinTest.c and tests/constraints.tcl: keep one copy of the command and the constraint (they are identical), and keep the tests of all branches.

Is he suggesting this change to menu.tcl:
...
proc ::tk::MenuFirstEntry menu {
+   MenuUnpost {}
...
It doesn't work for me.

The other hack 
-  bind Menubutton  <Alt-KeyPress> {
+ bind all <Alt-KeyPress> {
Also fails. Anyone have a working hack ?

The link's moved again:
https://groups.google.com/d/msg/comp.lang.tcl/FBckyyPemTI/Kh7HTHF2paEJ

Yes. It's totally broken isn't it. My project just  goes crazy as soon as you use the menu keyboard bindings, which is almost core usability imho.

Here's my  download link archive. Browse to the bin directory, and click on scid.exe to start program.
https://sourceforge.net/project/downloading.php?group_id=263836&filename=scid_vs_pc-windows-3.6.26.7.zip

Better URL to the article:
http://groups.google.com/group/comp.lang.tcl/msg/a1a576714cc71e2a?dmode=source