It was a bit weird to find because not all type of windows fail, but it affects windows like Firefox and Chrome.
To explain it a bit easier, if we imagine the screen as a table of 2x2, ControlClick will work fine when the window has a size and position similar to the cell A1 but will fail on A2, B1 and B2.
After searching it seems to be explained by lParam descriptions on different messages.
Values like WM_LBUTTONDOWN, WM_RBUTTONDOWN, WM_MBUTTONDOWN... are described as:
While WM_MOUSEWHEEL and WM_MOUSEHWHEEL, show this:lParam
The low-order word specifies the x-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area.
The high-order word specifies the y-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area.
Compensating the ControlClick by creating coordinates relative to screen seems to confirm this.lParam
The low-order word specifies the x-coordinate of the pointer, relative to the upper-left corner of the screen.
The high-order word specifies the y-coordinate of the pointer, relative to the upper-left corner of the screen.
This is some code that I used for testing (while moving the window around):
Code: Select all
f1::
WinGetPos, X, Y, W, H, A
control_desc := "x" X+W/2 " y" Y+H/2
control_desc := "" ; Comment the line out to apply the alternative.
ControlClick, %control_desc%, A, , WheelDown
Sleep, 300
ControlClick, %control_desc%, A, , WheelUp
return