Skip to main content

How do I get an AutomationElement directly from a WPF control? RRS feed

  • Question

  • We used the UI Automation framework to do some unit testing of a windows forms application on my last project. We have some code that can do some basic asserting and some manipulations of AutomationElements. Now we have started a WPF application and we would like to reuse the same code. For a windows forms control I can do the following

    Button button = new Button();

    AutomationElement element = AutomationElement.FromHandle(button.Handle);


    In WPF I can't figure out the equivalent. I know I can get a ButtonAutomationPeer from the Button but I don't know how to get the AutomationElement. I'm trying to avoid using TreeWalker or AutomationElement.FindFirst(...). Those aren't as efficient as direct access in a unit testing scenario. I took a look at AutomationElement.FromLocalProvider but I can't figure out how to get the IRawElementProviderSimple for the button. I tried the ProviderFromPeer method on AutomationPeer but it returns null. Does anyone know how to get the AutomationElement directly from the control?



    Thursday, February 15, 2007 4:18 PM

All replies

  • The WPF classes for UI Automation are provider-side only; see Clients don't obtain AutomationPeer or any of the provider interfaces; this is the job of the UI Automation core, which handles all communication between providers and clients.

    Also, it's risky to have the UI Automation client and the target elements in the same app, so getting the element via FromHandle is not typically the way it is done.

    I'll see what I can find out about getting the AutomationElement from the UIElement.


    Thursday, February 15, 2007 6:29 PM
  • There are 2 static methods on UIElementAutomationPeer: CreatePeerForElement, FromElement that will return an AutomationPeer for an item.

    This is not the AutomationElement, but the WPF-specific automation wrapper. It may be able to provide you with a set of data that you need for a given element.

    Thursday, February 15, 2007 8:57 PM
  • Thanks for the reply.

    It's an odd situation. Essentially I'm writing a wrapper above the UIAutomation layer. Seems like everyone is. Just look at the most recent Bugslayer column in the MSDN magazine. What I'm trying to do is unit test the wrapper I'm writing. So what I want is a quick and potentially dirty way to get an AutomationElement for a specific type of control in a specific framework. I understand the risks Peter pointed out in his post and I know I'm doing an atypical thing. I'd completely understand if there wasn't a way to do it.

    I've always got the option to add a layer of indirection between the framework I'm writing and the AutomationElement. That would allow interaction based testing (in other words prove that I make the expected calls to the AutomationElement) but it won't provide actual proof that I'm doing the right thing.

    Another option is to have a WPF application with the controls I want to test on it and let the unit tests find them. That's fine but that isn't ideal in a unit test scenario. It's slower and it makes each test depend on more than the functionality its testing. I'd rather avoid that.

    Thanks again for the help.


    Thursday, February 15, 2007 9:49 PM