AutomationProperties.Name VS x:Name

Posted 2023-03-30

【中文标题】AutomationProperties.Name VS x:Name

【英文标题】：

【发布时间】：2011-01-05 15:25:33

【问题描述】：

AutomationProperties.Name 和 x:Name 之间的“CodedUI 测试构建器”没有区别。但是第一个可以覆盖第二个。 AtomationProperties.Name 也支持数据绑定，x:Name 当然不支持。

As we know 如果您使用的是 MVVM 模式，最好只在需要时使用x:Name。

那么AutomationProperties.Name 应该优先于x:Name 吗？

【问题讨论】：

我已经阅读并纠正我的错误，但这篇文章并没有说你应该在任何地方使用一个而不是另一个它只是一篇关于：“我应该给所有东西一个名字吗？ ?”

@Silvermind 我已经更新了文字以更清楚地表明文章的内容。

@Trisped 这并没有改变我所说的事实。该链接与问题无关，它与 name 优先于 x:name 无关，反之亦然。

【参考方案1】：

总结

x:Name 和 AutomationProperties.Name 是两个完全不同的东西，所以“我应该使用一个还是另一个”这个问题是基于一个错误的前提：一般来说，你不能使用一个或另一个。

x:Name 的目的是在代码隐藏中识别 WPF 控件，以便开发人员可以访问它。在为特定 WPF 元素建模的类范围之外，它没有意义（或唯一）。

另一方面，AutomationProperties.Name 的目的是在呈现给用户进行交互的对话框或其他类型的窗口的上下文中识别用户界面元素。具体来说，它的值应该与用户认为的该用户界面元素的“标签”相匹配（例如，辅助工具可以告知用户该元素的用途）。

虽然任何工具（例如 XAML 编译器）都可以选择将 x:Name 的值用于 AutomationProperties.Name，但这并不意味着您应该这样做；恕我直言，这正是导致问题的“便利”类型，因为两者之间的差异对开发人员来说是隐藏的，因此总是一个或另一个属性最终会具有语义错误的值。

关于每个属性的语义和技术方面的信息将在接下来的部分中介绍。

x:名称

MSDN documentation 页面解释了这一点

在 x:Name 应用于框架的支持编程模型后， 该名称等同于保存对象引用的变量 或构造函数返回的实例。

x:Name 指令用法的值在 XAML 中必须是唯一的 名称范围。

[...]

在 WPF 应用程序的标准构建配置下，使用 XAML、部分类和代码隐藏，指定的 x:Name 变为 XAML 时在基础代码中创建的字段的名称 由标记编译构建任务处理，并且该字段包含 对对象的引用。

从上面我们可以看出x:Name：

用于访问代码（不是 XAML）中的元素，因为它控制包含元素的字段的名称 在XAML namescope 中必须是唯一的（因为代码中不能有两个同名的字段）

AutomationProperties.Name

WPF accessibility documentation 解释说

自动化元素的名称由开发人员指定。这 名称属性应始终与标签上的文字一致 屏幕。例如，按钮元素的名称必须是“Browse...” 以“浏览...”作为标签。

【讨论】：

所以我猜你也应该本地化 AutomationProperties.Name