System.Windows.Automation非常慢
System.Windows.Automation非常慢。
我执行：
element.FindAll(TreeScope.Children, Condition.TrueCondition); 在非常快的计算机上获得仅30个子元素可能需要1000毫秒。
我甚至看到它在QT应用程序中获取Tree的子元素时永远悬空。
这是一个已知的问题吗？ 谷歌搜索后我找不到任何有用的答案。
System.Windows.Automation非常慢 。
System.Windows.Automation充满了bug 。 它可能不会返回AutomationElement的所有子项，这是一个非常严重的错误。
除此之外，实现不是线程安全的 。
System.Windows.Automation已弃用。 不要用它！
在MSDN中，您可以找到以下注释：
UI Automation首先在Windows XP中作为Microsoft .NET Framework的一部分提供。 虽然当时还发布了非托管C ++ API，但由于互操作性问题，客户端function的用处受到限制。 对于Windows 7，API已在组件对象模型（COM）中重写。 尽管仍然记录了早期版本的UI Automation中引入的库函数，但它们不应在新应用程序中使用。
性能降低的解决方案是使用新的IUIAutomationElement COM接口而不是旧的System.Windows.Automation C＃接口。 之后代码将快速运行！
除此之外，新界面提供了更多的模式，微软正在不断扩展它。 在Windows 10 SDK（UIAutomationClient.h和UIAutomationCore.h）中，添加了几个在.NET Automation框架中不可用的模式和属性。
U.utomation的COM版本中提供了以下模式，这些模式在System.Windows.Automation中不存在：
- IUIAutomationLegacyIAccessiblePattern
- IUIAutomationObjectModelPattern
- IUIAutomationAnnotationPattern
- IUIAutomationTextPattern2
- IUIAutomationStylesPattern
- IUIAutomationSpreadsheetPattern
- IUIAutomationSpreadsheetItemPattern
- IUIAutomationTransformPattern2
- IUIAutomationTextChildPattern
- IUIAutomationDragPattern
- IUIAutomationDropTargetPattern
- IUIAutomationTextEditPattern
- IUIAutomationCustomNavigationPattern
此外，还添加了以下控件类型：
- AppBar
- SemanticZoom
此外，还添加了以下元素：
- IUIAutomationElement2
- IUIAutomationElement3
- IUIAutomationElement4
关于错误的是什么：新的COM UIAutomation Framework设计得非常好，我在框架的客户端找不到bug，与System.Windows.Automation相比，这是一个很大的进步。 但是在框架的服务器端有几个缺少的function甚至是错误。 在服务器端，每个GUI框架必须实现UIAutomation提供程序（请参阅MSDN：提供程序接口 ）。 所以这些问题根据您自动化的应用程序类型而有所不同，因为每个GUI框架都有自己的问题：
在Native Windows中，GUIfunction缺失：许多控件不实现它们应该实现的模式。 例如，本机工具栏中的SplitButton应实现Invoke模式以单击按钮和ExpandCollapse模式以打开下拉菜单。 但是缺少ExpandCollapse模式，这使得使用SplitButtons变得困难。 如果您通过IUIAutomation->ElementFromPoint()获得工具栏SplitButton，然后请求它的父级，您将获得一个残缺的元素。 并且寻呼机控制根本无法实现自动化。
此外，在WPF应用程序中，还有一些由Microsoft实现的控件：例如，如果您有一个Calendar控件，则会在顶部看到两个按钮以切换到下一个/上个月。 如果在这些按钮上执行Invoke模式，则会出现UIA_E_NOTSUPPORTED错误。 但这不是框架客户端的错误，因为对于其他按钮， Invoke模式可以正常工作。 这是WPF自动化服务器中的错误。 如果你用WPF RichTextBox测试IUIAutomationTextRange ，你会发现没有实现几个命令： Select()和ScrollIntoView()什么都不做。
对于.NET Forms应用程序， Microsoft并没有付出太多努力来支持它们。 .NET Calendar控件根本无法自动完成。 整个控件甚至不被识别为日历。 它具有ControlType“Pane”，其中没有子元素。 这同样适用于DateTimePicker 。 对于像DataGrid和PropertyGrid这样的复杂控件，唯一实现的模式是LegacyIAccessible ，这是一个很差的支持。 这些控件应至少实现Table和Grid以及ScrollItem模式。
此外， Internet Explorer无法自动执行，因为由于缺少坐标，可见区域外的元素无法自动滚动到视图中。 （Bounds以空矩形forms返回）并且未实现ScrollItem模式。 （是的，我知道Internet Explorer已经被Windows 10中的Edge取代，但是自从Windows 7和Microsoft在这些年中没有在Internet Explorer中实现有用的自动化支持时，UIAutomation框架就存在了）
我甚至看到了自动化应用程序的完全崩溃 。 例如，如果在某个控件上执行某些自动化命令，Visual Studio和TotalCommander将崩溃。 这里 – 再次 – 错误在于框架的服务器端实现。
简介：我们有一个很有用的框架。 开发新UIAutomation框架的Microsoft团队做得很好，但Microsoft的其他领域（原生GUI，WPF，.NET和Internet Explorer团队）不支持此框架。 这非常令人难过，因为只需要做很少的努力就可以提供更好的function。 但似乎残疾人并不是一个有利可图的市场。