Script freezing when GUI titlebar button held/clicked

[Descolada]

The following problems/bugs are most likely related to an already known problem described at keyboard_mouse.cpp L2194.

I did my testings in Windows 10 (build 19045.3693), AHK 2.0.10.

1) The script freezes while an AHK GUI titlebar button (eg Close) is held:

Code: Select all

#Requires AutoHotkey v2
gGui := Gui()
gGui.Show("w200 h200")
gGui.OnEvent("Close", (*) => ExitApp())
SetTimer((*) => ToolTip(A_TickCount), 100)

GuiFreeze1.gif (144.67 KiB) Viewed 370 times

2) The following script freezes and prevents any clicks being made if any of the titlebar buttons are clicked (WARNING: the script probably needs to be closed via Ctrl+Alt+Delete):

Code: Select all

#Requires AutoHotkey v2

CoordMode "Mouse", "Screen"
; SendMode "Event"
gGui := Gui()
gGui.Show("w200 h200")
gGui.OnEvent("Close", (*) => ExitApp())
SetTimer((*) => ToolTip(A_TickCount), 100)

*LButton::
{
    MouseGetPos(&X, &Y, &hWnd, &hCtrl)
    MouseClick("Left", X, Y, 1, 0, "D")
}
*LButton Up::MouseClick("Left", , , 1, 0, "U")

3) The previous script but with SendMode "Event" uncommented will not freeze.

4) There is about a 1 pixel wide region where a LButton remap will freeze the script:

Code: Select all

#Requires AutoHotkey v2

gGui := Gui()
gGui.Show("w200 h200")
gGui.OnEvent("Close", (*) => ExitApp())
SetTimer((*) => ToolTip(A_TickCount), 100)

F1::LButton

GuiFreeze2.gif (176.89 KiB) Viewed 337 times

It seems to be a Windows thing and probably can't be fixed, but perhaps some of the previously described scenarios can be included in the work-around?

[lexikos]

The default system handling of WM_NCLBUTTONDOWN captures the mouse and enters into a loop, which removes mouse messages from the queue until WM_NCLBUTTONUP is found, then terminates. Only mouse messages are removed from the queue; other messages are left in the queue and are not dispatched until the button is released. The process is not frozen; it is busy running this modal loop.

The workaround already in place requires that when SendInput is in use, the click is the first event in the sequence. Without this requirement, it would be difficult to predict where the mouse will be at the time the click is processed, or what window or button will be under it. Your example is not apparently moving the mouse, but including the coordinates in the parameter list causes a mouse-move event to be included in the sequence. If you omit the coordinates, the workaround will take effect.

The workaround is part of Send/Click/MouseClick, so is obviously not applicable to direct user input.

The 1 pixel region is where WM_NCHITTEST returns HTCAPTION even though the close button is highlighted.

A suggestion for #2: there's no need to use LButton as the hotkey. If you used F1 as in #4, there would be no need for the warning.