System.Windows.Automation非常slow.
System.Windows.Automation充满了bugs。它可能不会返回 AutomationElement 的所有子元素，这是一个非常严重的错误。
除此之外，实施是不是线程安全的.
System.Windows.Automation已弃用。不要使用它！
In the MSDN https://msdn.microsoft.com/en-us/library/windows/desktop/ee684076(v=vs.85).aspx你会发现以下注释：
UI 自动化首先在 Windows XP 中作为
微软.NET框架。尽管非托管 C++ API 也是
当时发布，客户端功能的用处有限
因为互操作性问题。对于 Windows 7，API 已
在组件对象模型 (COM) 中重写。
虽然早期版本引入的库函数
UI 自动化仍然有记录，它们不应该在新的中使用
应用程序。
性能缓慢的解决方案是使用新的IUI自动化元件COM 接口而不是旧的 System.Windows.Automation C# 接口。之后代码将运行快如闪电!
除此之外，新界面提供了更多模式，并且微软正在不断扩展它。在 Windows 10 SDK（UIAutomationClient.h 和 UIAutomationCore.h）中添加了 .NET 自动化框架中不可用的多个模式和属性。
以下模式在 UIAutomation 的 COM 版本中可用，但 System.Windows.Automation 中不存在：
- IUIAutomationLegacyIAccessiblePattern
- IUI自动化对象模型模式
- IUI自动化注释模式
- IUIAutomationTextPattern2
- IUI自动化样式模式
- IUI自动化电子表格模式
- IUIAutomationSpreadsheetItemPattern
- IUIAutomationTransformPattern2
- IUIAutomationTextChildPattern
- IUI自动化DragPattern
- IUI自动化DropTargetPattern
- IUI自动化文本编辑模式
- IUI自动化自定义导航模式
此外还添加了以下控件类型：
此外还添加了以下元素：
- IUI自动化元素2
- IUIAutomationElement 3
- IUIAutomationElement 4
以及什么问题bugs：新的 COM UIAutomation 框架设计得非常好，我在上面找不到错误客户端相比之下，这个框架是一个很大的进步System.Windows.Automation。但一些缺失的功能甚至是错误服务器端框架的。在服务器端，每个 GUI 框架必须实现一个 UIAutomation 提供程序（请参阅MSDN：提供商接口 https://msdn.microsoft.com/en-us/library/windows/desktop/ee671301%28v=vs.85%29.aspx）。因此，这些问题会根据您要自动化的应用程序类型而有所不同，因为每个 GUI 框架都有自己的问题：
In the 本机 Windows 图形用户界面缺少功能：许多控件没有实现它们应该实现的模式。例如一个分割按钮在本机工具栏中应该实现Invoke模式来单击按钮和ExpandCollapse模式来打开下拉菜单。但是ExpandCollapse缺少模式，这使得使用 SplitButtons 变得困难。如果您通过以下方式获得工具栏 SplitButtonIUIAutomation->ElementFromPoint()然后询问它的父元素，您将得到一个残缺的元素。还有Pager控制根本无法自动化。
Also in WPF应用程序有些控件是由 Microsoft 实现的有缺陷：例如，如果您有一个Calendar您可以在顶部看到两个按钮来切换到下个月/上个月。如果您执行Invoke这些按钮上的图案你会得到一个UIA_E_NOTSUPPORTED错误。但这不是框架客户端的错误，因为对于其他按钮Invoke模式工作正常。这是 WPF 自动化服务器中的一个错误。如果你测试IUIAutomationTextRange使用WPF RichTextBox，你会发现有几个命令没有实现：Select() and ScrollIntoView()什么都不做。
For .NET 表单应用程序微软并没有做出太多努力来支持他们。互联网Calendar控制根本无法自动化。整个控件甚至不被识别为日历。它具有 ControlType“Pane”，其中没有子元素。这同样适用于日期时间选择器。对于复杂的控制，例如DataGrid and 属性网格唯一实现的模式是LegacyIAccessible这是一个很差的支持。这些控制措施应至少实施Table和Grid和ScrollItem图案。
Also IE浏览器无法自动化，因为可见区域之外的元素由于缺少坐标而无法自动滚动到视图中。 （边界作为空矩形返回）并且ScrollItem模式未实施。 （是的，我知道 Internet Explorer 在 Windows 10 中已被 Edge 取代，但 UIAutomation 框架自 Windows 7 以来就存在，并且微软这些年来没有在 Internet Explorer 中实现有用的自动化支持）
我什至看到了完整的crashes的自动化应用程序。例如，如果您在某个控件上执行某些自动化命令，Visual Studio 和 TotalCommander 将崩溃。这里——再一次——错误在于框架的服务器端实现。
Summary:我们有一个很棒的框架，但实用性有限。开发新的 UIAutomation 框架的 Microsoft 团队做得很好，但 Microsoft 的其他领域（本机 GUI、WPF、.NET 和 Internet Explorer 团队）不支持该框架。这是非常可悲的，因为只需要付出一点努力就能提供更好的功能。但似乎最初使用 UIAutomation 的用户（残疾人）并不是一个有利可图的市场。
