Both UIAutomation and FlaUI define a class named AutomationElement, but they belong to different namespaces:
System.Windows.Automation.AutomationElement (Microsoft UIAutomation)
FlaUI.Core.AutomationElements.AutomationElement (FlaUI wrapper)
You might retrieve a native element from UIAutomation like this:
System.Windows.Automation.AutomationElement ele =
System.Windows.Automation.AutomationElement.FromHandle(handle);
Then, you want to use this element with FlaUI APIs.
Solution
You can wrap the native UIAutomation element using FlaUI’s UIA3Automation class:
using FlaUI.UIA3;
using FlaUI.Core.AutomationElements;
System.Windows.Automation.AutomationElement ele =
System.Windows.Automation.AutomationElement.FromHandle(handle);
using (var automation = new UIA3Automation())
{
AutomationElement flauiEle = automation.WrapNativeElement(ele);
// Now you can use flauiEle with FlaUI methods
}
This works because FlaUI provides WrapNativeElement() to take an existing UIAutomation element and wrap it into its own abstraction layer.
Honestly, I’ve bumped into this exact situation during one of my desktop automation projects. Since Microsoft UIAutomation’s AutomationElement and FlaUI’s AutomationElement come from different namespaces, you can’t just cast one to the other I actually learned this the hard way before checking the flaui documentation.
Here’s what consistently worked for me using UIA3Automation.WrapNativeElement():
using FlaUI.UIA3;
using FlaUI.Core.AutomationElements;
System.Windows.Automation.AutomationElement ele =
System.Windows.Automation.AutomationElement.FromHandle(handle);
using (var automation = new UIA3Automation())
{
AutomationElement flauiEle = automation.WrapNativeElement(ele);
}
Once wrapped, flauiEle behaves just like any other FlaUI element, and you can run all the FlaUI APIs on it without issues.
Yeah, I’ve been down this path as well, and @tim-khorev’s approach is spot-on. From my experience handling a migration from older UIAutomation scripts to FlaUI, using WrapNativeElement() is a lifesaver especially when you don’t want to rewrite tons of element-lookup logic.
After wrapping, you can immediately start using FlaUI features like .Click(), .Text, or .FindFirstDescendant() just like you would with elements created natively. I picked up this trick while digging through the flaui documentation, and it really smoothed out the transition.
Adding in questions my point because I ran into a small but important detail while doing this. When the original UIAutomation element isn’t fully visible or loaded yet, WrapNativeElement() will still return a wrapped object but actual interactions may fail until the UI is ready.
In my workflow, I started adding a quick readiness check like .IsEnabled or a short wait before performing actions, which saved me from flaky behavior. I remember noticing this caveat mentioned indirectly in the flaui documentation, and ever since then, things have been much more stable.