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