Microsoft文档有一些很好的信息:
默认情况下,当由.NET Framework XAML Services API使用时,主XAML名称范围在单个XAML生产的XAML根元素中定义,并包含该XAML生成中包含的元素.
这里要说的是,任何Xaml文档中的根元素都有为其创建的名称范围.无论元素是否实现INameScope(实际上没有核心UI元素),都会发生这种情况.
可以在单个XAML生成中发生的其他离散XAML名称范围可以由框架定义以解决特定方案.例如,在WPF中,新的XAML名称范围由任何也在该XAML生产中定义的模板定义和创建.有关XAML名称范围(为WPF编写但与许多XAML名称范围概念相关)的更多信息,请参阅WPF XAML名称范围.
除了为根元素创建的名称范围之外,还为Xaml生产中定义的任何模板隐式创建名称范围.这并不奇怪,作为FrameworkTemplate工具INameScope,因此这样做DataTemplate和ControlTemplate.还为Style元素创建名称范围.
您可能会注意到它ResourceDictionary也实现了INameScope,但它有点边缘情况:资源字典中的对象名称实际上并未在任何运行时名称范围中注册.如果你看一下实现,你会看到它的INameScope方法是抛出NotSupportedException,什么也不做,或者返回null.这种设计使名称很好地包含在内.它们被禁止在任何父作用域中注册,同时使它们可用于有限的目的,例如ElementName在a上使用引用Binding.重申一下,资源词典作为名称范围是一个边缘情况,实际上,你应该永远不必考虑.
除了上面概述的隐式创建的作用域之外,还为创建的对象实现的任何对象创建节点的Xaml解析器框架创建了新的名称作用域INameScope.与所有名称范围一样,注册名称在该范围内必须是唯一的; 但是,它们可能会与堆栈中其他名称范围内的名称发生冲突.
从Xaml实现对象时,XamlObjectWriter解析名称通过向上移动堆栈查找具有名称范围的帧,一旦找到包含所需名称的范围就停止.例如,在从x:Reference指令评估延迟引用时会发生这种情况.
它完全依赖于
INameScope界面,检查instance is INameScope?
它依赖于boolean财产XamlType.IsNameScope吗?
通常是后者,但通过确定类型是否可分配给INameScope映射到的Xaml 类型来设置该标志System.Windows.Markup.INameScope.它不检查运行时实例,而是检查XamlType相应对象创建节点的实例.从概念上讲,检查类似于typeof(INameScope).IsAssignableFrom(instanceType).
虽然你没有问过,但为了完整起见,我想谈谈最后一点:
何时在名称范围内注册对象?
这在两个条件下发生:
x:Name在Xaml元素上显式设置伪属性;FrameworkElement.Name,它被定义为运行时名称属性.喜欢的类型FrameworkElement有自己的Name财产,而不是强迫开发者指定Name并x:Name分别,他们提供一种方式来映射CLR属性x:Name.如果查看源代码FrameworkElement,您将看到一个[RuntimeNameProperty("Name")]属性.这告诉Xaml基础结构Nameany上的属性FrameworkElement对应x:Name,并且设置一个应该导致另一个被设置.请注意,运行时名称属性可以具有任何有效名称; 它不需要被称为Name.
| 归档时间: |
|
| 查看次数: |
134 次 |
| 最近记录: |