[BUG] AHKv2.0-a108 (Probably an old BUG)

Report problems with documented functionality
_3D_
Posts: 277
Joined: 29 Jan 2014, 14:40

[BUG] AHKv2.0-a108 (Probably an old BUG)

31 Dec 2019, 04:52

AHKv2.0-a108
Probably this is an old BUG.
Let see next example:

Code: Select all

Gui:= GuiCreate()
Gui.MenuBar:= MenuBarCreate()
Gui.MenuBar.Add("&File", FileMenu:= MenuCreate())
	FileMenu.Add("&Open`tCtrl+O", (*) => FileSelect())
	FileMenu.Add("E&xit", (*) => ExitApp())
Gui.MenuBar.Add("&Help", HelpMenu:= MenuCreate())	
	HelpMenu.Add("&About", (*) => MsgBox("Not implemented"))

;Gui.Add("Text",, "[BUG] Label") ;<<< uncomment to start work
Gui.Show("w300 h200")
When GUI has not any control Alt+Letter not work in MenuBar.
At the given example when uncomment line Gui.Add("Text",, "[BUG] Label") Alt+Letter start to work. It is interesting that internal Ctlr+O shortcut work in both cases.
AHKv2.0 alpha forever.
swagfag
Posts: 6222
Joined: 11 Jan 2017, 17:59

Re: [BUG] AHKv2.0-a108 (Probably an old BUG)

31 Dec 2019, 10:36

interesting
Alt Down, Alt Up, F will still bring up the file menu
Alt Down, F, [Alt Up](optional) however won't
whereas both hotkey sequences work with the "non-empty" gui

the Ctrl + O accelerator is irrelevant. i suspect this might be a windows thing, but i dont know enough about menus to say for sure
lexikos
Posts: 9583
Joined: 30 Sep 2013, 04:07
Contact:

Re: [BUG] AHKv2.0-a108 (Probably an old BUG)

12 Apr 2020, 21:53

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.

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 42 guests