AutomationProperties.Name VS x：名称
AutomationProperties.Name和x:Name之间的“CodedUI测试生成器”没有区别。 但第一个可以覆盖第二个。 AtomationProperties.Name也支持数据绑定， x:Name当然不支持。
我们知道如果您使用的是MVVM模式，最好只在需要时使用x:Name 。
那么AutomationProperties.Name应该优先于x:Name吗？
概要
x:Name和AutomationProperties.Name是两个完全不同的东西，所以“我应该使用其中一个还是另一个”这个问题是基于一个错误的前提：一般来说，你不能使用其中一个。
x:Name的目的是在代码隐藏中识别WPF控件，以便开发人员可以访问它。 它不是模拟特定WPF元素的类范围之外的有意义的（或唯一的）。
另一方面， AutomationProperties.Name的目的是在向用户展示交互的对话框或其他类型的窗口的上下文中标识用户界面元素。 具体来说，其值应该与用户会认为该用户界面元素的“标签”相匹配（以便例如可访问性工具可以通知用户该元素的用途）。
虽然任何工具（例如XAML编译器）都可以选择使用AutomationProperties.Name的x:Name的值，但这并不意味着它是您应该执行的操作; 恕我直言，这正是导致问题的“便利”的类型，因为两者之间的差异对开发人员来说是隐藏的，所以总是一个或另一个属性最终会产生语义错误的值。
有关每个属性的语义和技术方面的信息将在下一节中介绍。
X：名称
MSDN文档页面解释了这一点
将x：Name应用于框架的支持编程模型后，该名称等同于包含由构造函数返回的对象引用或实例的变量。
x：Name指令用法的值在XAML名称范围内必须是唯一的。
[...]
在使用XAML，部分类和代码隐藏的WPF应用程序的标准构建配置下，指定的x：Name成为当标记编译构建任务处理XAML时在基础代码中创建的字段的名称，并且该字段提供对该对象的引用。
从上面我们可以看出x:Name ：
AutomationProperties.Name
WPF辅助功能文档解释了这一点
自动化元素的名称由开发人员分配。 名称属性应始终与屏幕上的标签文本保持一致。 例如，名称必须是“浏览...”，按钮元素以“浏览...”作为标签。
链接地址: http://www.djcxy.com/p/21231.html