System.Windows.Automation extremely slow .
System.Windows.Automation is full of errors . It cannot return all AutomationElement children, which is a very serious error.
In addition, the implementation is not thread-oriented .
System.Windows.Automation deprecated. Do not use it!
In MSDN you will find the following note:
UI Automation was first available in Windows XP as part of the Microsoft .NET Framework. Although the unmanaged C ++ API was also published at that time, the utility of client functions was limited due to compatibility issues. For Windows 7, the API has been rewritten in the Component Object Model (COM). Although the library functions introduced in the earlier version of UI Automation are still documented, they should not be used in new applications.
The solution to reduce performance is to use the new IUIAutomationElement COM interface instead of the old C # System.Windows.Automation interface. After that, the code will work with lightning speed !
In addition, the new interface offers much more templates, and Microsoft is constantly expanding it. The Windows 10 SDK (UIAutomationClient.h and UIAutomationCore.h) added several templates and properties that are not available in the .NET Automation environment.
The following templates are available in the COM version of UIAutomation, which are not available in System.Windows.Automation:
- IUIAutomationLegacyIAccessiblePattern
- IUIAutomationObjectModelPattern
- IUIAutomationAnnotationPattern
- IUIAutomationTextPattern2
- IUIAutomationStylesPattern
- IUIAutomationSpreadsheetPattern
- IUIAutomationSpreadsheetItemPattern
- IUIAutomationTransformPattern2
- IUIAutomationTextChildPattern
- IUIAutomationDragPattern
- IUIAutomationDropTargetPattern
- IUIAutomationTextEditPattern
- IUIAutomationCustomNavigationPattern
Additionally, the following types of controls have been added:
Additionally, the following element was added:
- IUIAutomationElement2
- IUIAutomationElement3
- IUIAutomationElement4
And as for the bugs : The new COM UIAutomation Framework is very well designed, and I could not find any errors on the client side, which is a big improvement over System.Windows.Automation . But a few missing features and even errors on the server side of the framework. On the server side, each GUI structure must implement the UIAutomation provider (see MSDN: Providers Interfaces ). Thus, these problems differ depending on what type of application you automate, because each GUI framework has its own problems:
Native Windows does not have GUI functions: many controls do not implement the templates that they must implement. For example, SplitButton on its own toolbar should implement an Invoke template for a button click and an ExpandCollapse template to open a drop-down menu. But the ExpandCollapse pattern ExpandCollapse missing, which makes using SplitButtons difficult. If you get the SplitButton toolbar using IUIAutomation->ElementFromPoint() and then request its parent element, you will get a damaged element. And pager control cannot be automated at all.
Also in WPF applications there are controls that are implemented by Microsoft with errors: for example, if you have a Calendar control , you see two buttons at the top to switch to the next / previous month. If you run the Invoke pattern for these buttons, you will get the UIA_E_NOTSUPPORTED error. But this is not a mistake on the client side of the framework, because for other buttons the Invoke template works correctly. This is a bug on the WPF automation server. And if you test IUIAutomationTextRange with WPF RichTextBox, you will find that several commands are not implemented: Select() and ScrollIntoView() just do nothing.
For .NET Forms applications, Microsoft makes little effort to support them. The .NET Calendar control cannot be automated at all. The entire control is not even recognized as a calendar. It has a ControlType "Pane" with no children. The same applies to DateTimePicker . And for complex controls, such as DataGrid and PropertyGrid, the only implemented template is LegacyIAccessible which is poorly supported. These controls must implement at least the Table Grid and ScrollItem .
Also, Internet Explorer cannot be automated, because elements outside the visible area cannot automatically scroll in the field of view due to missing coordinates. (The borders are returned as an empty rectangle) And the ScrollItem template ScrollItem not implemented. (Yes, I know that Internet Explorer was replaced by Edge in Windows 10, but the UIAutomation infrastructure exists because Windows 7 and Microsoft have not implemented useful automation support in Internet Explorer all these years)
I have even seen complete crashes in an automated application. For example, Visual Studio and TotalCommander will crash if you run certain automation commands on a specific control. Here - again - the error lies in implementing the server-side infrastructure.
Summary: we have a great limited utility structure. The Microsoft team that developed the new UIAutomation platform has done a great job, but other areas in Microsoft (native GUI team, WPF, .NET, and Internet Explorer) do not support this platform. This is very sad because only a little effort is required to improve functionality. But it seems that users who primarily use UIAutomation (people with disabilities) are not a profitable market.