System.Windows.Automation非常慢 [英] System.Windows.Automation is extremely slow

查看：549
本文介绍了System.Windows.Automation非常慢的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

System.Windows.Automation非常慢。



我执行：

  element.FindAll（TreeScope.Children， Condition.TrueCondition）;

在非常快的计算机上，仅获取30个子元素可能需要1000毫秒。



我什至看到它在QT应用程序中获取Tree的子元素时永久悬挂。



这是一个已知问题吗？
经过大量搜索后，我找不到任何有用的答案。

解决方案

System.Windows。自动化 慢。



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



此外，该实现是不是线程安全的。 / p>

System.Windows.Automation 已弃用。不要使用它！



在 MSDN ，您会发现以下注释：


UI Automation作为
Microsoft .NET Framework的一部分首次在Windows XP中提供。尽管当时还发布了非托管C ++ API
，但是由于互操作性问题，客户端功能的有用性受到限制。对于Windows 7，已在组件对象模型（COM）中重写了
。
尽管仍记录了早期版本的
UI Automation中引入的库函数，但不应在新的
应用程序中使用它们。


降低性能的解决方案是使用新的 IUIAutomationElement COM接口，而不是旧的System.Windows.Automation C＃接口。之后，代码将闪电般快速运行！



除此之外，新界面还提供了更多的模式，Microsoft也在不断扩展它。在Windows 10 SDK（UIAutomationClient.h和UIAutomationCore.h）中，添加了.NET自动化框架中不可用的几种模式和属性。



以下模式可在System.Windows.Automation中不存在的UIAutomation的COM版本中使用：




  • IUIAutomationLegacyIAccessiblePattern

  • IUIAutomationObjectModelPattern

  • IUIAutomationAnnotationPattern

  • IUIAutomationTextPattern2

  • IUIAutomationStylesPattern

  • IUIAutomationSpreadsheetPattern

  • IUIAutomationSpreadsheetItemPattern

  • IUIAutomationTransformPattern2

  • IUIAutomationTextChildPattern

  • IUIAutomationDragPattern

  • IUIAutomationDropTargetPattern

  • IUIAutomationTextEditPattern

  • IUIAutomationCustomNavigationPattern



另外添加了以下控件类型d：




  • AppBar

  • SemanticZoom



另外还添加了以下元素：




  • IUIAutomationElement2

  • IUIAutomationElement3

  • IUIAutomationElement4



与 bug 有关的问题：新的COM UIAutomation框架经过精心设计，我无法在该框架的客户端上发现错误，与 System.Windows.Automation 相比，这是一个很大的进步code>。但是框架的服务器端缺少一些功能，甚至还存在一些错误。在服务器端，每个GUI框架都必须实现UIAutomation提供程序（请参阅 MSDN：提供商接口）。因此，这些问题取决于要自动化的应用程序类型而有所不同，因为每个GUI框架都有其自身的问题：



在本地Windows GUI 功能中丢失：许多控件未实现应实现的模式。例如，本机工具栏中的 SplitButton 应该实现 Invoke 模式以单击按钮，并使用 ExpandCollapse 模式以打开下拉菜单。但是缺少 ExpandCollapse 模式，这使得使用SplitButtons变得困难。如果通过 IUIAutomation-> ElementFromPoint（）获取工具栏SplitButton，然后要求其父项，您将获得残缺的元素。而且 Pager 控件根本无法实现自动化。



在 WPF应用程序中，还有一些实现了错误的控件微软公司：例如，如果您有一个日历控件，您会在顶部看到两个按钮以切换到下一个/上一个月。如果在这些按钮上执行 Invoke 模式，则会出现 UIA_E_NOTSUPPORTED 错误。但这不是框架客户端的错误，因为对于其他按钮， Invoke 模式可以正常工作。这是WPF自动化服务器中的错误。而且，如果使用WPF RichTextBox测试 IUIAutomationTextRange ，您会发现没有实现以下几个命令： Select（）和 ScrollIntoView（）根本不执行任何操作。



对于 .NET Forms应用程序，Microsoft并未付出很多努力来支持它们。 .NET 日历控件完全不能自动化。整个控件甚至都无法识别为日历。它具有ControlType Pane，其中没有子元素。 DateTimePicker 也是如此。对于 DataGrid 和 PropertyGrid 这样的复杂控件，唯一实现的模式是 LegacyIAccessible ，这是一个较差的支持。这些控件应至少实现 Table 和 Grid 和 ScrollItem 模式。



此外， Internet Explorer 无法自动执行，因为由于缺少坐标，无法将可见区域之外的元素自动滚动到视图中。 （边界以一个空矩形返回）并且未实现 ScrollItem 模式。 （是的，我知道Internet Explorer在Windows 10中已被Edge取代，但是UIAutomation框架存在，因为Windows 7和Microsoft多年来一直没有在Internet Explorer中实现有用的自动化支持）



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



总结：我们有一个很好的框架，但实用性有限。开发新的UIAutomation框架的Microsoft团队做得很好，但是Microsoft的其他区域（本机GUI，WPF，.NET和Internet Explorer团队）不支持此框架。这是非常可悲的，因为只需要付出很小的努力就可以提供更好的功能。但是，似乎首先使用UIAutomation的用户（残障人士）不是一个有利可图的市场。


System.Windows.Automation is EXTREMELY slow.

I execute:

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

Obtaining only 30 child elements may take 1000ms on a very fast computer.

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 is EXTREMELY slow.

System.Windows.Automation is full of bugs. It may not return all children of an AutomationElement, which is a very severe bug.

Apart from that the implementation is not thread safe.

System.Windows.Automation is deprecated. Do not use it!

In the MSDN you find the following note:

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.

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!

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.

The following patterns are available in the COM version of UIAutomation which do not exist in System.Windows.Automation:

  • IUIAutomationLegacyIAccessiblePattern
  • IUIAutomationObjectModelPattern
  • IUIAutomationAnnotationPattern
  • IUIAutomationTextPattern2
  • IUIAutomationStylesPattern
  • IUIAutomationSpreadsheetPattern
  • IUIAutomationSpreadsheetItemPattern
  • IUIAutomationTransformPattern2
  • IUIAutomationTextChildPattern
  • IUIAutomationDragPattern
  • IUIAutomationDropTargetPattern
  • IUIAutomationTextEditPattern
  • IUIAutomationCustomNavigationPattern

Additionally the following Control types have been added:

  • AppBar
  • SemanticZoom

Additionally the following Element's have been added:

  • IUIAutomationElement2
  • IUIAutomationElement3
  • IUIAutomationElement4

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:

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.

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.

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.

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)

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.

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非常慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
C#/.NET最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆