CODEWITHSUNDEEP
c#windowswinapiui-automation
TMS
TMS

Reputation: 139

How to figure out what a general hWnd represents?

According to MSDN, winAPI functions like WindowFromPoint do not return all top level windows (skips hidden and disabled at least), and then we need to use more flixable functions such as ChildWindowFromPoint.

However, the last function can return not only window, you may get any child control handle.

So my question is how I should distinguish the actual type of the object that I have its handle, is it a Window, button, checkbox ..etc.

When I tried to "define" what is Window\Form to check it manually (like if it has a title bar), the borders between different object are really fuzzy.

Getting class name of course not an option, since they are pretty arbitrary generally speaking.

Finally I found that Microsoft Automation UI in .Net Framework some how manages to distinguish objects, any clue how this is done?. It seems that like one needs to implement a complex mechanism, that will compare many parameters to verify what it is really, but then how AUI so sure about what it found?

Upvotes: 0

Views: 113

Answers (1)

IInspectable
IInspectable

Reputation: 51489

So my question is how I should distinguish the actual type of the object that I have its handle, is it a Window, button, checkbox ..etc.

You can call GetClassName on the window handle to retrieve a textual representation of the window class. While this may help identify standard control classes, it is of little help for custom window classes (those introduced by calling RegisterClassEx).

Window classes are static1, and any window of a particular window class can later change some of the settings specified in the class template. To retrieve up-to-date window information, you can use GetWindowLongPtr instead.

I found that Microsoft Automation UI in .Net Framework some how manages to distinguish objects, any clue how this is done?

UI Automation does not rely on window handles at all. It works by inspecting and manipulating the accessible tree, that's implemented through COM interfaces. There is no strict relation between native window handles and accessible objects (that's why it works for window-less controls as well, as used by the majority of browsers, for example).

how AUI so sure about what it found?

Because it doesn't second-guess what the UI Automation interfaces return. Those are implemented by the control author, so it can be assumed to be trustworthy information.

1 That's approximately correct. You can still modify a registered class by calling SetClassLongPtr.

Upvotes: 4

Related Questions