WPF中NameScope的查找规则详解

前言

我们在 wpf 中使用绑定时可以使用 elementname=foo 这样的写法，并且还能够真的在运行时找到这个名称对应的对象，是因为 wpf 中提供了名称范围概念。

实现 inamescope 接口可以定义一个名称范围。无论你使用 name 属性还是使用 x:name 特性都可以在一个名称范围内指定某个元素的名称。绑定时就在此名称范围内查找，于是可以找到你需要的对象。

xaml中的namescope

首先来讲讲wpf的名称管理机制namescope，也即是名称范围。名称范围主要提供了两种功能：记录xaml名称与界面元素实例之间的关联关系；防止名称冲突。可以说，第二种功能是第一种功能实现时所产生的副作用。而在xaml中引用某个名称时，wpf会自动使用相应的namescope执行对名称的查找。

那么，wpf的名称范围是如何在xaml等程序组成中起作用的呢？如果一个元素在xaml中使用x:name或name属性设置了名称，那么wpf会为该属性设置执行一些额外的执行逻辑，如在对应的cs文件中自动生成具有相同名称的成员，并将它们注册到相应的名称范围中。如果在该范围中多次使用了相同的名称，那么wpf会抛出一个异常。在xaml中对某个元素进行引用的时候，wpf会从该namescope中寻找该名称所对应的界面元素以进行操作。

当然，用户并不需要显式地对名称范围进行处理。默认情况下，wpf会使用一定的机制保证该文件中的各个界面元素可以拥有合适的名称范围。在xaml中常常作为根元素的page类及window类都提供了对名称范围的支持。如果xaml中的根元素并不是这两个类型，那么xaml处理器会在处理过程中为该文件隐式地添加一个page元素作为新的根元素。通过这种方法，wpf可以保证xaml文件中对x:name以及name的使用可以将名称正确地注册进相应的名称范围中。

本文将介绍 wpf 中 namescope 的查找规则。（额外的，资源 / 资源字典的查找方式与 namescope 的方式是一样的，所以本文分析过程同样使用与资源的查找。）

inamescope

wpf 的 inamescope 接口只用来管理一个范围之内的名称。它包含下面三个方法：

public interface inamescope
{
 object findname(string name);
 void registername(string name, object scopedelement);
 void unregistername(string name);
}

它的主要实现是 namescope，包含了更多功能；而上面的接口是其本2222质功能。

不过，namescope 的实现带来了一个重要的依赖项属性 —— namescope。下面是此属性的代码（经过简化）：

public static readonly dependencyproperty namescopeproperty
 = dependencyproperty.registerattached("namescope", typeof(inamescope), typeof(namescope));

public static void setnamescope(dependencyobject dependencyobject, inamescope value)
{
 if (dependencyobject == null) throw new argumentnullexception(nameof(dependencyobject));
 dependencyobject.setvalue(namescopeproperty, value);
}

public static inamescope getnamescope(dependencyobject dependencyobject)
{
 if (dependencyobject == null) throw new argumentnullexception(nameof(dependencyobject));
 return ((inamescope)dependencyobject.getvalue(namescopeproperty));
}

同样实现了此接口的还有 templatenamescope，此 namescope 会被 frameworktemplate / frameworkelementfactory / bamlrecordreader 设置到以上依赖属性中。于是我们可以在模板范围内找到某个特定名称对应的元素。

除此之外，namescope 的设置由 xaml 解析器在 wpf 项目编译的时候自动生成。

namescope 的名称注册规则

如果你没有在代码中显式去调用 registername 这样的方法，那么 namescope 的创建以及名称的注册都由 xaml 解析器来完成。

xaml 解析器（bamlrecordreader）注册名字的时候并没有去爬可视化树什么的，只是单纯在解析 xaml 的时候去调用代码注册这个名字而已。注册由一个 stack 来完成，namescopestack。

设想以下这个例子（来自于 .net framework 代码中的注释）：

<window x:name="mywindow">
 ...
 <style x:name="mystyle">
 ...
 <solidcolorbrush x:name="mybrush">
 </solidcolorbrush>
 </style>
</window>

每当 xaml 解析器解析一层的时候，就会给 namescopestack 入栈，于是 window 首先创建 namescope 入栈。随后解析到 style 时又加一个 namescope 入栈，其他元素解析时不会创建 namescope（包括 xaml 中的顶层元素 usercontrol 等）。

这时，mywindow 会被注册到 window 一层的 namescope 中，mystyle 也会注册到 window 一层的 namescope 中；而 mybrush 则会注册到 style 那一层的 namescope 中。

window 的 namescope

• mywindow
• mystyle

style 的 namescope

• mybrush

namescope 的名称查找规则

在本文一开始贴出 namescope 依赖项属性的时候，你应该注意到这只是一个普通的属性，并没有使用到什么可以用可视化树继承这样的高级元数据。事实上也不应该有这样的高级元数据，因为 namescope 的抽象级别低于可视化树或者逻辑树。

但是，实际上 namescope 的查找却是依赖于逻辑树的 —— 这是 frameworkelement 的功能：

internal static inamescope findscope(dependencyobject d, out dependencyobject scopeowner)
{
 while (d != null)
 {
  inamescope namescope = namescope.namescopefromobject(d);
  if (namescope != null)
  {
   scopeowner = d;
   return namescope;
  }

  dependencyobject parent = logicaltreehelper.getparent(d);

  d = (parent != null) ? parent : helper.findmentor(d.inheritancecontext);
 }

 scopeowner = null;
 return null;
}

非常明显，findscope 是期望使用逻辑树来查找名称范围的。

不过值得注意的是，当一个元素没有逻辑父级的时候，会试图使用 helper.findmentor 来查找另一个对象。那这是什么方法，又试图寻找什么对象呢？

mentor 是名词，意为 “导师，指导”。于是我们需要阅读以下 helper.findmentor 方法的实现来了解其意图：

提示：以下注释中的 fe 代表 frameworkelement，而 fce 代表 frameworkcontentelement。

/// <summary>
///  this method finds the mentor by looking up the inheritancecontext
///  links starting from the given node until it finds an fe/fce. this
///  mentor will be used to do a findresource call while evaluating this
///  expression.
/// </summary>
/// <remarks>
///  this method is invoked by the resourcereferenceexpression
///  and bindingexpression
/// </remarks>
internal static dependencyobject findmentor(dependencyobject d)
{
 // find the nearest fe/fce inheritancecontext
 while (d != null)
 {
  frameworkelement fe;
  frameworkcontentelement fce;
  helper.downcasttofeorfce(d, out fe, out fce, false);

  if (fe != null)
  {
   return fe;
  }
  else if (fce != null)
  {
   return fce;
  }
  else
  {
   d = d.inheritancecontext;
  }
 }

 return null;
}

具体来说，是不断查找 inheritancecontext，如果找到了 frameworkelement 或者 frameworkcontentelement，那么就返回这个 fe 或者 fce；如果到最终也没有找到，则返回 null。

这是个 virtual 属性，基类 dependencyobject 中只返回 null，而子类重写它时，返回父级。freezable, frameworkelement, frameworkcontentelement 等重写了这个属性。

对于 frameworkelement，重写时只是单纯的返回了一个内部管理的字段而已：

internal override dependencyobject inheritancecontext
{
 get { return inheritancecontextfield.getvalue(this); }
}

此字段在调用 dependencyobject.addinheritancecontext 的时候会赋值。而对于可视化树或逻辑树的建立，此方法不会被调用，所以此属性并不会对可视化树或逻辑树有影响。但是，freezable, inputbinding, visual3d, gridviewcolumn, viewbase, collectionviewsource, resourcedictionary, triggeraction, triggerbase 等会在属性赋值的时候调用此方法。于是我们能够在以上这些属性的设置中找到名称。

特别说明，只有那些重写了 inheritancecontext 的类型才会在查找名称的时候找得到 namescope；只有以上这些调用了 dependencyobject.addinheritancecontext 方法的属性才会在赋值是能够找得到 namescope。

所以，我另一篇文章中所说的 contextmenu 是找不到对应的 namescope 的。wpf 的 elementname 在 contextmenu 中无法绑定成功？试试使用 x:reference！。此文中 contextmenu 找到的 namescope 是 null。

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。