ControlGetClassNN error with Win10 Win+v Clipboard

[ludamo]

When trying to detect the Class name of the Win10 (Win+v) clipboard AHK v 2.0.2.0 throws an error. Using the same procedure on Win 10 Calculator works OK. OS Name : Windows 10 Pro (64-bit) OS Version : 22H2 OS Build : 19045.2364.

Code: Select all

#Requires AutoHotkey v2.0
WheelDown::
WheelUp:: {

MouseGetPos(,,&hWndM)
TT := "MouseGetPos hWndM:`t" Format("0x{:X}", hWndM) "`t" WinGetClass(hWndM)

MouseGetPos(,,,&hCtrl,2)
TT .= "`nMouseGetPos hCtrl: `t" Format("0x{:X}", hCtrl) "`t" WinGetClass(hCtrl)

Try TT .= "`nControlGetClassNN :`t" ControlGetClassNN(hCtrl)

Try MouseGetPos(,,,&hCtrlNN)
Try TT .= "`nMouseGetPos CtrlNN:`t" hCtrlNN

Tooltip TT
}

[swagfag]

When trying to detect the Class name of the Win10 (Win+v) clipboard

it seems to me ure detecting the class name just fine. the exception is thrown when u try to retrieve the ClassNN, but what exactly is the ahk bug ure trying to report?

[ludamo]

Well, for the Clipboard I can get the class name OK with WinGetClass but ControlGetClassNN throws the error, whereas for Calculator both work OK.
That is MouseGetPos gets the control handle OK (Option 2 Stores the control's HWND in OutputVarControl rather than the control's ClassNN) but throws an error if determining the classNN.

[swagfag]

ive ran some tests on windows10. the clipboard widget has these windows

image.png (25.48 KiB) Viewed 1009 times

of which, regardless of whether the widget is being shown or not, none are enumerable with EnumChildWindows() which is what ControlGetClassNN() is based on internally. why that is i cant say, maybe u can ask someone from microsoft(its not a message-only window, so there must be another reason)

---

and the Calculator has these windows

image.png (34.52 KiB) Viewed 1009 times

of which all are enumerable. u can enumerate the inenumerable windows with a custom loop based on FindWindowEx(), so maybe this could be used instead as a fallback method

[ludamo]

Thanks for looking into this further. I have had a look at the source code since but still can't quite understand where the failure is. MouseGetPos with option 2 can get the hWnd of the Win10 clipboard child window 'Windows.UI.Core.CoreWindow' OK and then if I use the Windows function 'GetClassName' (which is the one used in the source code to get the ClassNN - win.cpp line 757) I am able to get the class successfully but using MouseGetPos with option 0, i.e directly trying to get the ClassNN it seems to fail.

[swagfag]

if u want to understand where the failure is, u need to...

...ask someone from microsoft...

...what exactly causes EnumChildWindows() to fail to enumerate anything when a window belonging to the "Win10 Win+v Clipboard" popup is specified

---

its pointless to try MouseGetPos(), since that also delegates to ControlGetClassNN() internally

---

the only thing u can do currently to (kind of) fix this urself, is write ur own version of ControlGetClassNN() that instead enumerates windows with DllCall FindWindowsEx(). the generation of NNs is simple, just increment a number when u encounter a window with the same classname: https://github.com/AutoHotkey/AutoHotkey/blob/27a2d5f2ae392c9d2cf2ef1a2f136659831749b8/source/lib/win.cpp#L780
but these ControlNNs uve generated urself wont be particularly useful besides for ur own printing purposes, since u cant pass them around to other ahk functions that expect actual ahk-detectable ControlNNs

[lexikos]

An Error or OSError is thrown if the ClassNN could not be determined.

The ClassNN could not be determined, so an Error was thrown, as documented.

EnumChildWindows is used not only to calculate the ClassNN of a control, but also to resolve a ClassNN to a control HWND. The "NN" sequence number is based on the order of enumeration by EnumChildWindows. If a child window is not enumerated by EnumChildWindows, it cannot possibly have a ClassNN.

The child windows shown in the screenshot above are not a controls in the traditional sense, but child windows created internally by the UWP app framework. However, other UWP apps have these child windows, apparently without this issue.

When trying to detect the Class name ...

Class name != ClassNN.