none
CUIAutomationClass vs AutomationElement (which one should I use?) RRS feed

  • Question

  • hello!

    I am writing some heavy duty Automation code, and have found myself digging a bit into the source of .net AutomationClient.

    I have noticed that in AutomationElement.cs there are calls to the function UiaFind, located in AutomationCore.dll.

    The documentation of UiaFind says the following:

    Note  This function is deprecated. Client applications should use the Microsoft UI Automation Component Object Model (COM) interfaces instead.

    So, I had a look at the provided COM dll UIAutomationClient. seems it provides the same functionality to the underlying automation technology.

    my question is this : what is the recommended approach?

    A - Use the .net AutomationElement object, which provides a nice interface to the underlying functionality, but uses a deprecated dll?

    B - Use the class CUIAutomationClass exposed by the COM dll, as recommended by the documentation?

    or perhaps there is another, better approach?

    Thanks

    Eran Broder

    Tuesday, November 26, 2019 11:26 AM

Answers

  • Depending on who you talk to... UIAutomationClient is built on top of Windows Automation 2.0 where the COM interface is based on Windows Automation 3.0. Modern applications most likely will be supporting Windows Automation 3.0 natively. Applications made a decade ago may support 2.0. QT applications made before 2018 would only support the even older API MSAA. If you use the wrong version of Automation API there's a chance the targeting application will misbehave or the element might not even be exposed, as the automation provider in the application may not be tested with the API version you are using. If the application being automated is written by yourself then use the COM API as it is the fastest, and use a modern GUI framework that has support for Windows Automation 3.0 when writing your application. And test, test, test. Windows Automation 3.0 has higher performance then predecessors but that might be bad for your application if you now got more commands than you can handle.

    There's a UIAComWrapper project on github that you can use if you don't want to port your old UIAutomationClient code. But it hasn't been updated for years and might not be suitable if you want to use the new Automation APIs introduced in recent versions of Windows 10. 



    Visual C++ MVP






    Tuesday, November 26, 2019 6:21 PM

All replies

  • Depending on who you talk to... UIAutomationClient is built on top of Windows Automation 2.0 where the COM interface is based on Windows Automation 3.0. Modern applications most likely will be supporting Windows Automation 3.0 natively. Applications made a decade ago may support 2.0. QT applications made before 2018 would only support the even older API MSAA. If you use the wrong version of Automation API there's a chance the targeting application will misbehave or the element might not even be exposed, as the automation provider in the application may not be tested with the API version you are using. If the application being automated is written by yourself then use the COM API as it is the fastest, and use a modern GUI framework that has support for Windows Automation 3.0 when writing your application. And test, test, test. Windows Automation 3.0 has higher performance then predecessors but that might be bad for your application if you now got more commands than you can handle.

    There's a UIAComWrapper project on github that you can use if you don't want to port your old UIAutomationClient code. But it hasn't been updated for years and might not be suitable if you want to use the new Automation APIs introduced in recent versions of Windows 10. 



    Visual C++ MVP






    Tuesday, November 26, 2019 6:21 PM
  • WOW.

    What a perfect answer.

    Thank you so much!

    Wednesday, November 27, 2019 8:53 AM