前言

我們在 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。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對VEVB武林網的支持。