This bug has probably existed for as long as there were GUIs with menu bars.
Modeless dialog boxes like AutoHotkey's GUIs use IsDialogMessage() to handle keyboard navigation and accelerators within the dialog. If it is not called, DefDlgProc or DefWindowProc will handle WM_SYSCHAR (Alt+
F) by activating the menu. If IsDialogMessage is called for WM_SYSCHAR, it always consumes the message (returns true to indicate it was already handled). Debugging shows that it normally does handle the message - the menu bar is activated.
However, if the GUI itself has the focus (
DllCall("GetFocus", "ptr") returns the GUI), it seems IsDialogMessage will still consume the WM_SYSCHAR message but will not activate the menu. Normally when a dialog receives focus, it transfers focus to one of its controls, but this obviously cannot happen if it has no enabled controls.
Until this is fixed, one can use the workaround shown above; add a single control, which can be hidden but not disabled. A Text control will suffice and will actually receive the focus, even though it can't normally be focused by clicking the mouse or pressing Tab.
v1:
Code: Select all
Menu, MyMenuBar, Add, &File, MenuHandler
Menu, MyMenuBar, Add, &Help, MenuHandler
Gui, Menu, MyMenuBar
; Gui, Add, Text, Hidden ; Test before/after uncommenting this.
Gui, Show, w300 h100
hwnd := DllCall("GetFocus", "ptr")
WinGetClass class, ahk_id %hwnd%
Menu, MyMenuBar, Add, Focus: %class%, MenuHandler
return
MenuHandler:
MsgBox %A_ThisMenuItem%
return
GuiEscape: ; This is also handled via IsDialogMessage().
ExitApp
@_3D_ In future, please include in the title at least one word actually relating to the bug or problem. Also, bug reports should go in the Bug Reports forum, or in Ask for Help (v1 or v2 forum as appropriate) prior to confirmation of the bug. The v2 development forum (which is where I found this) is not a suitable place for such topics.