WPF控件开发之自定义控件(3)

创建 UserControl
如前所述，在 WPF 中创建控件的最简单方法是从 UserControl 派生。下面的示例演示用于定义 NumericUpDownUserControl 的 用户界面 (UI) 的 XAML：

 

下面的示例演示此 UserControl 的逻辑。

 

如此示例所示，自定义 UserControl 的开发模型非常类似于用于应用程序开发的模型。

创建自定义控件
生成支持模板的控件
UserControl 提供了一种简单方法在 WPF 中生成可重用的功能，但要利用模板化和支持不同主题，则要使用的模型为 Control。本节将上一节中的 UserControl 示例转换为自定义 Control。

更改基类
首先，将 UserControl 基类替换为 Control。

移动到模板
一旦更新了基类，则需要将控件的内容移动到模板。模板在可位于应用程序中的很多位置的样式中定义。对于此示例，样式位于应用程序资源中。

在 UserControl 示例中，TextBlock 和 RepeatButton 实例已指定了名称。RepeatButton 实例还引用了代码中定义的事件处理程序。可以在此自定义 Control 中移除这两个实例，因为将通过更松散耦合的方式，改为使用绑定和命令来获取相同的行为。

 

处理输入
在 UserControl 示例中，RepeatButton 实例直接引用了代码中定义的事件处理程序。对于自定义 Control，命令是实现相同行为的一种更灵活的方式。控件可以定义命令，如下面的示例所示。

 

然后，模板中的元素可以引用这些命令，如下面的示例所示。

 

通过定义模板以及使用绑定和命令，您已将 NumericUpDown 控件从具有固定可视化效果的静态 UserControl 更改为可灵活自定义的自定义 Control。

外部控件库
最后一步是将 NumericUpDown 控件打包到其自己的程序集中，以使重用更容易。

创建主题文件
将 NumericUpDown 类移动到库程序集之后，需要移动样式定义。首先，需要创建一个“themes”文件夹用于存储所有主题文件。接下来，创建一个名为 generic.xaml 的文件。此文件将用作此程序集的所有资源查找的回退。

在 generic.xaml 中定义一个 ResourceDictionary，并在 ResourceDictionary 中放置 NumericUpDown 控件的样式。

定义 ThemeInfo 属性
若要找到 generic.xaml 中的 Style，宿主应用程序需要知道该程序集包含控件特定的资源。可以通过向类中添加程序集属性来实现该任务。由于程序集仅包含一般资源，因此将 GenericDictionaryLocation 属性设置为 SourceAssembly。下面的示例显示了 AssemblyInfo.cs 文件的内容。

 

为 Windows 主题提供支持
一个控件在大量不同 WPF主题中可能有不同的外观。若要支持多个主题，必须使用控件所需的正确样式、模板和其他资源来定义主题文件。还需要将 ThemeInfoAttribute 属性 (Attribute) 的 ThemeDictionaryLocation 属性 (Property) 设置为引用源程序集，如下面的示例所示。

 

本文档概述在设计可方便地样式化和模板化的控件时需要考虑的一组最佳做法。在为内置的 WPF 控件集处理主题控件样式时，我们通过大量试验和错误总结出了这组最佳做法。我们已经认识到，成功的样式化不只是设计完善的对象模型的功能，也是样式本身的功能。本文档面向控件作者，而不是样式作者。

术语
“样式化和模板化”是一组技术，控件作者可以通过该组技术来将控件的可视化特性延迟到控件的样式和模板。这组技术包括：

样式（包括属性 setter、触发器和演示图板）。

资源。

控件模板。

数据模板。

准备工作：了解您的控件
在开始阅读本文档中的准则之前，一定要了解并定义了控件的一般用法，这一点很重要。样式化公开一组通常不受约束的可能性。旨在由许多开发人员在许多应用程序中广泛使用的控件面临着如下挑战：可以使用样式化来对控件的可视化外观进行广泛的更改。实际上，带有样式的控件甚至可能并非控件作者的本意。由于样式化在本质上可以提供无限的灵活性，因此您可以使用“一般用法”这一概念来帮助您限制自己的决定。

为了了解控件的一般用法，最好考虑控件的价值主张。您的控件能够提供哪些无法由其他控件提供的内容？ 一般用法并不表示任何特定的可视化外观，而是表示控件的基本原理和一组有关其用法的合理预期。了解到这一点，就可以对控件在一般情况下的撰写模型和样式定义行为进行一些假设。例如，对于 ComboBox，如果您了解其一般用法，并不意味着您非常清楚特定的 ComboBox 是否有圆角，但是您将由此清楚 ComboBox 可能需要一个弹出窗口和某种用来切换其开关状态的方法。

通用准则
不严格实施模板约定。 控件的模板约定可以包含元素、命令、绑定和触发器，甚至还可以包含必需的或为了使控件正常工作而应当使用的属性设置。

尽可能减少约定。

围绕如下预期来设计：在设计时（即，在使用设计工具时），控件模板通常处于不完整状态。WPF 不提供“正在撰写”状态的基础结构，因此，控件必须围绕这样的状态可能有效这一预期来生成。

在没有遵循模板约定的任何方面时，不引发异常。按照这一原则，当面板的子级太多或太少时，面板不应当引发异常。

将外围功能分解成模板帮助器元素。 每个控件都应当将重点放在其核心功能和真正的价值主张上，而且每个控件都应当由控件的一般用法来定义。为此，请使用模板中的撰写和帮助器元素来实现外围行为和可视化，即，那些不构成控件核心功能的行为和可视化。帮助器元素可分为三类：

独立帮助器类型是以“匿名方式”用在模板中的可重用的公共控件或基元，这意味着帮助器元素和带有样式的控件无法互相识别。在技术上，任何元素都可以是匿名类型，但是在这里，术语“独立”用于描述那些封装专用功能以实现目标方案的类型。

基于类型的帮助器元素是封装专用功能的新类型。通常，这些元素在设计上比公用控件或基元的功能范围要窄。与独立帮助器元素不同的是，基于类型的帮助器元素能够识别它们的使用上下文，而且通常必须与包含它们所属模板的控件共享数据。

命名的帮助器元素是控件应当能够在其模板中根据名称找到的公用控件或基元。这些元素在模板中具有一个已知的名称，这使得控件能够找到这些元素并以编程方式与之交互。在任何模板中，都只能有一个具有给定名称的元素。

下表显示的是由目前的控件样式使用的部分帮助器元素列表：