WPF中NameScope的查找規(guī)則是什么

這篇文章將為大家詳細(xì)講解有關(guān)WPF中NameScope的查找規(guī)則是什么，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對相關(guān)知識(shí)有一定的了解。

XAML中的NameScope

首先來講講WPF的名稱管理機(jī)制NameScope，也即是名稱范圍。名稱范圍主要提供了兩種功能：記錄XAML名稱與界面元素實(shí)例之間的關(guān)聯(lián)關(guān)系；防止名稱沖突?？梢哉f，第二種功能是第一種功能實(shí)現(xiàn)時(shí)所產(chǎn)生的副作用。而在XAML中引用某個(gè)名稱時(shí)，WPF會(huì)自動(dòng)使用相應(yīng)的NameScope執(zhí)行對名稱的查找。

那么，WPF的名稱范圍是如何在XAML等程序組成中起作用的呢？如果一個(gè)元素在XAML中使用x:Name或Name屬性設(shè)置了名稱，那么WPF會(huì)為該屬性設(shè)置執(zhí)行一些額外的執(zhí)行邏輯，如在對應(yīng)的cs文件中自動(dòng)生成具有相同名稱的成員，并將它們注冊到相應(yīng)的名稱范圍中。如果在該范圍中多次使用了相同的名稱，那么WPF會(huì)拋出一個(gè)異常。在XAML中對某個(gè)元素進(jìn)行引用的時(shí)候，WPF會(huì)從該NameScope中尋找該名稱所對應(yīng)的界面元素以進(jìn)行操作。

當(dāng)然，用戶并不需要顯式地對名稱范圍進(jìn)行處理。默認(rèn)情況下，WPF會(huì)使用一定的機(jī)制保證該文件中的各個(gè)界面元素可以擁有合適的名稱范圍。在XAML中常常作為根元素的Page類及Window類都提供了對名稱范圍的支持。如果XAML中的根元素并不是這兩個(gè)類型，那么XAML處理器會(huì)在處理過程中為該文件隱式地添加一個(gè)Page元素作為新的根元素。通過這種方法，WPF可以保證XAML文件中對x:Name以及Name的使用可以將名稱正確地注冊進(jìn)相應(yīng)的名稱范圍中。

本文將介紹 WPF 中 NameScope 的查找規(guī)則。（額外的，資源 / 資源字典的查找方式與 NameScope 的方式是一樣的，所以本文分析過程同樣使用與資源的查找。）

INameScope

WPF 的 INameScope 接口只用來管理一個(gè)范圍之內(nèi)的名稱。它包含下面三個(gè)方法：

public interface INameScope
{
 object FindName(string name);
 void RegisterName(string name, object scopedElement);
 void UnregisterName(string name);
}

它的主要實(shí)現(xiàn)是 NameScope，包含了更多功能；而上面的接口是其本2222質(zhì)功能。

不過，NameScope 的實(shí)現(xiàn)帶來了一個(gè)重要的依賴項(xiàng)屬性 —— NameScope。下面是此屬性的代碼（經(jīng)過簡化）：

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));
}

同樣實(shí)現(xiàn)了此接口的還有 TemplateNameScope，此 NameScope 會(huì)被 FrameworkTemplate / FrameworkElementFactory / BamlRecordReader 設(shè)置到以上依賴屬性中。于是我們可以在模板范圍內(nèi)找到某個(gè)特定名稱對應(yīng)的元素。

除此之外，NameScope 的設(shè)置由 XAML 解析器在 WPF 項(xiàng)目編譯的時(shí)候自動(dòng)生成。

NameScope 的名稱注冊規(guī)則

如果你沒有在代碼中顯式去調(diào)用 RegisterName 這樣的方法，那么 NameScope 的創(chuàng)建以及名稱的注冊都由 XAML 解析器來完成。

XAML 解析器（BamlRecordReader）注冊名字的時(shí)候并沒有去爬可視化樹什么的，只是單純在解析 XAML 的時(shí)候去調(diào)用代碼注冊這個(gè)名字而已。注冊由一個(gè) Stack 來完成，NameScopeStack。

設(shè)想以下這個(gè)例子（來自于 .NET Framework 代碼中的注釋）：

<Window x:Name="myWindow">
 ...
 <Style x:Name="myStyle">
 ...
 <SolidColorBrush x:Name="myBrush">
 </SolidColorBrush>
 </Style>
</Window>

每當(dāng) XAML 解析器解析一層的時(shí)候，就會(huì)給 NameScopeStack 入棧，于是 Window 首先創(chuàng)建 NameScope 入棧。隨后解析到 Style 時(shí)又加一個(gè) NameScope 入棧，其他元素解析時(shí)不會(huì)創(chuàng)建 NameScope（包括 XAML 中的頂層元素 UserControl 等）。

這時(shí)，myWindow 會(huì)被注冊到 Window 一層的 NameScope 中，myStyle 也會(huì)注冊到 Window 一層的 NameScope 中；而 myBrush 則會(huì)注冊到 Style 那一層的 NameScope 中。

Window 的 NameScope

• myWindow

• myStyle

Style 的 NameScope

• myBrush

NameScope 的名稱查找規(guī)則

在本文一開始貼出 NameScope 依賴項(xiàng)屬性的時(shí)候，你應(yīng)該注意到這只是一個(gè)普通的屬性，并沒有使用到什么可以用可視化樹繼承這樣的高級元數(shù)據(jù)。事實(shí)上也不應(yīng)該有這樣的高級元數(shù)據(jù)，因?yàn)?NameScope 的抽象級別低于可視化樹或者邏輯樹。

但是，實(shí)際上 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;
}

非常明顯，F(xiàn)indScope 是期望使用邏輯樹來查找名稱范圍的。

不過值得注意的是，當(dāng)一個(gè)元素沒有邏輯父級的時(shí)候，會(huì)試圖使用 Helper.FindMentor 來查找另一個(gè)對象。那這是什么方法，又試圖尋找什么對象呢？

Mentor 是名詞，意為 “導(dǎo)師，指導(dǎo)”。于是我們需要閱讀以下 Helper.FindMentor 方法的實(shí)現(xiàn)來了解其意圖：

提示：以下注釋中的 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，那么就返回這個(gè) FE 或者 FCE；如果到最終也沒有找到，則返回 null。

這是個(gè) virtual 屬性，基類 DependencyObject 中只返回 null，而子類重寫它時(shí)，返回父級。Freezable, FrameworkElement, FrameworkContentElement 等重寫了這個(gè)屬性。

對于 FrameworkElement，重寫時(shí)只是單純的返回了一個(gè)內(nèi)部管理的字段而已：

internal override DependencyObject InheritanceContext
{
 get { return InheritanceContextField.GetValue(this); }
}

此字段在調(diào)用 DependencyObject.AddInheritanceContext 的時(shí)候會(huì)賦值。而對于可視化樹或邏輯樹的建立，此方法不會(huì)被調(diào)用，所以此屬性并不會(huì)對可視化樹或邏輯樹有影響。但是，F(xiàn)reezable, InputBinding, Visual3D, GridViewColumn, ViewBase, CollectionViewSource, ResourceDictionary, TriggerAction, TriggerBase 等會(huì)在屬性賦值的時(shí)候調(diào)用此方法。于是我們能夠在以上這些屬性的設(shè)置中找到名稱。

關(guān)于WPF中NameScope的查找規(guī)則是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。