Created attachment 323543 [details]
Untested patch

I started implementing this because the old UIAutomationWinformsClientTests use it, and I thought they would be useful to run.  But I ran into some issues and then realized that they could be related to running the tests in the same process as the form, which I'm not ready to be testing.

But anyway, here's my work-in-progress, basically untested patch, which only implements it for UiaDbus.

Whoever picks up this bug may find this handy.

Updating hours

Committed, leaving open because I need to open some new bugs and don't want to forget (see review).

Currently we implement the FromHandle by reversely searching every AutomationElement's NativeWindowHandle property.
However, AutomationElements and native handles are not one-to-one mapped. It's possible for an AutomationElement to have several native window handles (including the one stored in NativeWindowHandle property).

E.g. with our SWF UIAutomationClientTests, the textBox1 control, which is 100 * 20 in pixel, actually consists of actally 2 windows (one for the body and the other one for the border):

0x7200030 (has no name): ()  100x20+102+56  +105+80
1 child:
    0x7200031 (has no name): ()  96x16+2+2  +107+82

textBox1's NativeWindowHandle is 0x7200031, however IMO, the result of FromHandle (new IntPtr(0x7200030)) shall not be null, but also be textBox1's AutomationElement.

Adding some hours.