System.Windows.Automation 非常慢.
System.Windows.Automation is EXTREMELY slow.
我执行:
element.FindAll(TreeScope.Children, Condition.TrueCondition);
在速度非常快的计算机上，仅获取 30 个子元素可能需要 1000 毫秒.
Obtaining only 30 child elements may take 1000ms on a very fast computer.
我什至看到它在 QT 应用程序中获取 Tree 的子元素时永远挂起.
I have even seen it hanging forever while getting the child elements of a Tree in a QT application.
这是一个已知问题吗?谷歌搜索了很多后，我找不到任何有用的答案.
Is this a known problem? I cannot find any usefull answer after googling a lot.
System.Windows.Automation 非常慢.
System.Windows.Automation 充满了错误.它可能不会返回 AutomationElement 的所有子项，这是一个非常严重的错误.
System.Windows.Automation is full of bugs. It may not return all children of an AutomationElement, which is a very severe bug.
除此之外，实现是不是线程安全的.
System.Windows.Automation 已弃用.不要使用它！
System.Windows.Automation is deprecated. Do not use it!
在 MSDN 你会发现以下注释:
In the MSDN you find the following note:
UI 自动化最初是在 Windows XP 中作为微软 .NET 框架.虽然非托管 C++ API 也是当时发布，客户端功能的用处有限因为互操作性问题.对于 Windows 7，API在组件对象模型 (COM) 中重写.虽然在早期版本中引入的库函数UI 自动化仍然记录在案，它们不应该用于新的应用程序.
UI Automation was first available in Windows XP as part of the Microsoft .NET Framework. Although an unmanaged C++ API was also published at that time, the usefulness of client functions was limited because of interoperability 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.
降低性能的解决方案是使用新的 IUIAutomationElement COM 接口，而不是旧的 System.Windows.Automation C# 接口.之后代码将运行闪电般的速度！
The solution to slow performance is to use the new IUIAutomationElement COM interface instead of the old System.Windows.Automation C# interface. After that the code will be running lightning fast!
除此之外，新界面还提供了更多模式，Microsoft 正在不断对其进行扩展.在 Windows 10 SDK(UIAutomationClient.h 和 UIAutomationCore.h)中，添加了一些在 .NET 自动化框架中不可用的模式和属性.
Apart from that the new interface offers much more patterns and Microsoft is extending it continously. In the Windows 10 SDK (UIAutomationClient.h and UIAutomationCore.h) several patterns and properties have been added which are not available in the .NET Automation framework.
以下模式在 UIAutomation 的 COM 版本中可用，而 System.Windows.Automation 中不存在:
The following patterns are available in the COM version of UIAutomation which do not exist in System.Windows.Automation:
另外还添加了以下控件类型:
Additionally the following Control types have been added:
另外还添加了以下元素:
Additionally the following Element's have been added:
关于错误:新的 COM UIAutomation 框架设计得非常好，我在框架的客户端上找不到错误，这是一个很大的进步与 System.Windows.Automation 相比.但是框架的服务器端 缺少一些功能甚至是错误.在服务器端，每个 GUI 框架都必须实现 UIAutomation 提供程序(请参阅 MSDN:提供者接口).因此，这些问题因您要自动化的应用程序类型而异，因为每个 GUI 框架都有自己的问题:
And what concerns the bugs: The new COM UIAutomation Framework is very well designed and I could not find bugs on the client side of the framework which is a great progress compared to System.Windows.Automation. But several missing features and even bugs on the server side of the framework. On the server side each GUI framework must implement an UIAutomation provider (see MSDN: Interfaces for Providers). So these problems differ depending on what type of application you are automating because each GUI framework has it's own problems:
本机 Windows GUI 功能缺失:许多控件没有实现它们应该实现的模式.例如，原生工具栏中的 SplitButton 应实现 Invoke 模式以单击按钮，并实现 ExpandCollapse 模式以打开下拉菜单.但是缺少 ExpandCollapse 模式，这使得拆分按钮很难使用.如果您通过 IUIAutomation->ElementFromPoint() 获得 Toolbar SplitButton，然后询问它的父级，您将获得一个残缺的元素.而且 Pager 控件根本无法自动化.
In the Native Windows GUI features are missing: Lots of controls do not implement the patterns that they should implement. For example a SplitButton in a native Toolbar should implement the Invoke pattern to click the button and the ExpandCollapse pattern to open the drop-down menu. But the ExpandCollapse pattern is missing which makes it difficult to use SplitButtons. If you obtain a Toolbar SplitButton by IUIAutomation->ElementFromPoint() and then ask for it's parent you will get a crippled element. And the Pager control cannot be automated at all.
此外，在 WPF 应用程序中，Microsoft 实现的一些控件存在缺陷:例如，如果您有一个 日历 控件，您会在顶部看到两个按钮来切换到下/上个月.如果您在这些按钮上执行 Invoke 模式，您将收到 UIA_E_NOTSUPPORTED 错误.但这不是框架客户端的错误，因为对于其他按钮，Invoke 模式可以正常工作.这是 WPF 自动化服务器中的一个错误.如果你用 WPF RichTextBox 测试 IUIAutomationTextRange，你会发现有几个命令没有实现: Select() 和 ScrollIntoView() 做的很简单没有什么.
Also in WPF applications there are controls that are implemented buggy by Microsoft: For example if you have a Calendar control you see two buttons at the top to switch to the next/previous month. If you execute the Invoke pattern on these buttons you will get an UIA_E_NOTSUPPORTED error. But this is not a bug on the client side of the framework, because for other buttons the Invoke pattern works correctly. This is a bug in the WPF Automation server. And if you test IUIAutomationTextRange with a WPF RichTextBox, you will find that several commands are not implemented: Select() and ScrollIntoView() do simply nothing.
对于 .NET Forms 应用程序，Microsoft 没有做出太多努力来支持它们..NET 日历 控件根本无法自动化.整个控件甚至不被识别为日历.它具有 ControlType窗格"，其中没有子元素.这同样适用于 DateTimePicker.而对于像 DataGrid 和 PropertyGrid 这样的复杂控件，唯一实现的模式是 LegacyIAccessible ，它的支持很差.这些控件至少应该实现 Table 和 Grid 以及 ScrollItem 模式.
For .NET Forms applications Microsoft did not make much effort to support them. The .NET Calendar control cannot be automated at all. The entire control is not even recognized as Calendar. It has the ControlType "Pane" with no child elements in it. The same applies to the DateTimePicker. And for complex controls like DataGrid and PropertyGrid the only implemented pattern is LegacyIAccessible which is a poor support. These controls should implement at least the Table and the Grid and the ScrollItem pattern.
此外，Internet Explorer 无法自动化，因为可见区域之外的元素由于缺少坐标而无法自动滚动到视图中.(边界作为一个空矩形返回)并且 ScrollItem 模式没有实现.(是的，我知道在 Windows 10 中 Internet Explorer 已经被 Edge 取代了，但是 UIAutomation 框架从 Windows 7 开始就存在了，而且微软这些年来并没有在 Internet Explorer 中实现有用的自动化支持)
Also Internet Explorer cannot be automated because elements outside the visible area cannot be scrolled automatically into view due to missing coordinates. (The Bounds are returned as an empty rectangle) And the ScrollItem pattern is not implemented. (Yes, I know that Internet Explorer has been replaced with Edge in Windows 10, but the UIAutomation framework exists since Windows 7 and Microsoft did not implement a usefull automation support in Internet Explorer in all these years)
我什至看到了自动化应用程序的完整崩溃.例如，如果您在某个控件上执行某些自动化命令，Visual Studio 和 TotalCommander 将会崩溃.这里 - 再次 - 错误在于框架的服务器端实现.
I saw even complete crashes of the automated application. For example Visual Studio and TotalCommander will crash if you execute certain automation commands on a certain control. Here - once again - the bug lies in the server side implementation of the framework.
总结:我们有一个很好的框架，但用处有限.开发新 UIAutomation 框架的微软团队做得很好，但微软的其他领域(原生 GUI、WPF、.NET 和 Internet Explorer 团队)不支持这个框架.这是非常可悲的，因为只需要付出很小的努力就可以提供更好的功能.但似乎首先使用 UIAutomation 的用户(残疾人)并不是一个有利可图的市场.
Summary: We have a great framework with limited usefullness. The Microsoft team that developed the new UIAutomation framework did a great job, but the other areas in Microsoft (the native GUI, WPF, .NET and Internet Explorer team) do not support this framework. This is very sad because only a small effort would have to be made to offer a better functionality. But it seems that the users who use UIAutomation in the first place (handicapped people) are not a profitable market.
这篇关于System.Windows.Automation 非常慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！