System.Windows.Automation非常慢

System.Windows.Automation非常慢.

我执行:

element.FindAll(TreeScope.Children, Condition.TrueCondition);

在非常快的计算机上获得仅30个子元素可能需要1000ms.

我甚至看到它在QT应用程序中获取Tree的子元素时永远挂起.

这是一个已知的问题吗？谷歌搜索后我找不到任何有用的答案.

System.Windows.Automation非常慢.

System.Windows.Automation充满了虫子.它可能不会返回AutomationElement的所有子项,这是一个非常严重的错误.

除此之外,实现不是线程安全的.

System.Windows.Automation已弃用.不要用它!

在MSDN中,您可以找到以下注释:

UI自动化作为Microsoft .NET Framework的一部分首次在Windows XP中提供.虽然当时还发布了非托管C++ API,但由于互操作性问题,客户端功能的用处受到限制.对于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设计得非常好,我无法在框架的客户端发现错误,这是一个很大的进步System.Windows.Automation.但是在框架的服务器端有几个缺失的功能甚至是错误.在服务器端,每个GUI框架必须实现UIAutomation提供程序(请参阅MSDN:提供程序接口).因此,这些问题根据您自动化的应用程序类型而有所不同,因为每个GUI框架都有自己的问题:

在Native Windows中,GUI功能缺失:许多控件没有实现它们应该实现的模式.例如,本机工具栏中的SplitButton应该实现Invoke模式以单击按钮和ExpandCollapse模式以打开下拉菜单.但ExpandCollapse缺少模式,这使得使用SplitButtons变得困难.如果您获得工具栏SplitButton IUIAutomation->ElementFromPoint(),然后请求它的父级,您将获得一个残缺的元素.并且寻呼机控制根本无法实现自动化.

此外,在WPF应用程序中,有一些控件由Microsoft实现错误:例如,如果您有一个Calendar控件,您会在顶部看到两个按钮切换到下一个/上个月.如果Invoke在这些按钮上执行模式,则会出现UIA_E_NOTSUPPORTED错误.但这不是框架客户端的错误,因为对于其他按钮,Invoke模式正常工作.这是WPF自动化服务器中的错误.如果你IUIAutomationTextRange使用WPF RichTextBox进行测试,你会发现没有实现几个命令:Select()并且ScrollIntoView()什么都不做.

对于.NET Forms应用程序, Microsoft并没有付出太多努力来支持它们..NET Calendar控件根本无法自动完成.整个控件甚至不被识别为日历.它具有ControlType"Pane",其中没有子元素.这同样适用于DateTimePicker.对于像DataGrid和PropertyGrid这样的复杂控件,唯一实现的模式是LegacyIAccessible支持不佳.这些控件应该至少实现Table和Grid和ScrollItem模式.

此外,Internet Explorer无法自动执行,因为可见区域外的元素由于缺少坐标而无法自动滚动到视图中.(边界作为空矩形返回)并且ScrollItem未实现模式.(是的,我知道Internet Explorer已经被Windows 10中的Edge取代,但是自从Windows 7和Microsoft在这些年中没有在Internet Explorer中实现有用的自动化支持时,UIAutomation框架就存在了)

我甚至看到了自动化应用程序的完全崩溃.例如,如果在某个控件上执行某些自动化命令,Visual Studio和TotalCommander将崩溃.这里 - 再次 - 错误在于框架的服务器端实现.

简介:我们有一个很有用的框架.开发新UIAutomation框架的Microsoft团队做得很好,但Microsoft的其他领域(原生GUI,WPF,.NET和Internet Explorer团队)不支持此框架.这非常令人难过,因为只需要做很少的努力就可以提供更好的功能.但似乎残障人士并不是一个有利可图的市场.