WPF学习--路由事件

什么是路由事件？ 
可以从功能或实现的角度来考虑路由事件。此处对这两种定义均进行了说明，因为用户当中有的认为前者更有用，而有的则认为后者更有用。

功能定义：路由事件是一种可以针对元素树中的多个侦听器（而不是仅针对引发该事件的对象）调用处理程序的事件。

实现定义：路由事件是一个 CLR 事件，可以由 RoutedEvent 类的实例提供支持并由 Windows Presentation Foundation (WPF) 事件系统来处理。

典型的 WPF 应用程序中包含许多元素。无论这些元素是在代码中创建的还是在 XAML 中声明的，它们都由共同所在的元素树关联起来。根据事件的定义，事件路由可以按两种方向之一传播，但是通常会在元素树中从源元素向上“冒泡”，直到它到达元素树的根（通常是页面或窗口）。如果您以前用过 DHTML 对象模型，则可能会熟悉这个冒泡概念。

请考虑下面的简单元素树：

在这个简化的元素树中，Click 事件的源是某个 Button 元素，而所单击的 Button 是有机会处理该事件的第一个元素。但是，如果附加到 Button 的任何处理程序均未作用于该事件，则该事件将向上冒泡到元素树中的 Button 父级（即 StackPanel）。该事件可能会冒泡到 Border，然后会到达元素树的页面根（未显示出来）。

换言之，此 Click 事件的事件路由为：

Button-->StackPanel-->Border-->...

路由事件的顶级方案
下面简要概述了需运用路由事件的方案，以及为什么典型的 CLR 事件不适合这些方案：

控件的撰写和封装：WPF 中的各个控件都有一个丰富的内容模型。例如，可以将图像放在 Button 的内部，这会有效地扩展按钮的可视化树。但是，所添加的图像不得中断命中测试行为（该行为会使按钮响应对图像内容的 Click），即使用户所单击的像素在技术上属于该图像也是如此

单一处理程序附加点：在 Windows 窗体中，必须多次附加同一个处理程序，才能处理可能是从多个元素引发的事件。路由事件使您可以只附加该处理程序一次（像上例中那样），并在必要时使用处理程序逻辑来确定该事件源自何处。例如，这可以是前面显示的 XAML 的处理程序：

 

 

用来添加标准 CLR 事件处理程序的 XAML 语法与用来添加路由事件处理程序的语法相同，因为您实际上是在向下面具有路由事件实现的 CLR 事件包装中添加处理程序。

路由策略 

路由事件使用以下三个路由策略之一：

冒泡：针对事件源调用事件处理程序。路由事件随后会路由到后续的父元素，直到到达元素树的根。大多数路由事件都使用冒泡路由策略。冒泡路由事件通常用来报告来自不同控件或其他 UI 元素的输入或状态变化。

XAML 

<Window x:Class="Wpfceshi.Window1"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="Window1" Height="300" Width="300" MouseDown="Window_MouseDown"  >

    <Grid MouseDown="Grid_MouseDown" x:Name="grid">

        <Button Height="30" Width="100" Content="点击我" MouseDown="Button_MouseDown"/>

    </Grid>

</Window>

code 

using System.Windows;

using System.Windows.Input;

namespace Wpfceshi

{

    /// <summary>

    /// Window1.xaml 的交互逻辑

    /// </summary>

    public partial class Window1 : Window

    {

        public Window1()

        {

            InitializeComponent();

        }

private void Window_MouseDown(object sender, MouseButtonEventArgs e)

        {

            MessageBox.Show("Window被点击");

        }

private void Grid_MouseDown(object sender, MouseButtonEventArgs e)

        {

            MessageBox.Show("Grid被点击");

        }

private void Button_MouseDown(object sender, MouseButtonEventArgs e)

        {

            MessageBox.Show("Button被点击");

        }

    }

}

我们会发现当点击button按钮时，button，Grid，window中的事件都会触发，这就是冒泡路由策略的功能所在,事件首先在源元素上触发，然后从每一个元素向上沿着树传递，直到到达根元素为止（或者直到处理程序把事件标记为已处理为止），从而调用这些元素中的路由事件。

事件标记为已处理的情况为：如果把button的事件修改为：

private void Button_MouseDown(object sender, MouseButtonEventArgs e)
{
MessageBox.Show("Button被点击");
e.Handled = true;
}

则以上事件就不会沿着button-grid-window执行下去，而是只执行button的事件。

如果在以上代码的基础上，还要执行grid 的事件的话，那就需要修改代码：

public Window1()
{
InitializeComponent();
grid.AddHandler(Grid.MouseDownEvent, new RoutedEventHandler(Grid_MouseDown1), true);
}

然后添加这个新事件Grid_MouseDown1

private void Grid_MouseDown1(object sender, RoutedEventArgs e)
{
MessageBox.Show("Grid被点击");
}

这样就是冒泡式

直接：只有源元素本身才有机会调用处理程序以进行响应。这与 Windows 窗体用于事件的“路由”相似。但是，与标准 CLR 事件不同的是，直接路由事件支持类处理（类处理将在下一节中介绍）而且可以由 EventSetter 和 EventTrigger 使用。

事件仅仅在源元素上触发，这个与普通的.Net事件的行为相同，不同的是这样的事件仍然会参与一些路由事件的特定机制，如事件触发器等。

该事件唯一可能的处理程序是与其挂接的委托。

路由事件的事件处理程序的签名：

他与通用的.net事件处理程序的模式一致，也有两个参数：第一个为：System.Object对象，名为sender，第二个参数（一般名为e）是一个派生于System.EventArgs的类。sender参数就是该处理程序被添加的元素，参数e是RoutedEventArgs的一个实例提供了4个有用的属性：

Source---逻辑树中开始触发该事件的的元素。

originalSource--可视树中一开始触发该事件的元素。

handled---布尔值，设置为true表示事件已处理，在这里停止。

RoutedEvent---真正的路由事件对象，（如Button.ClickEvent）当一个事件处理程序同时用于多个路由事件时，它可以有效地识别被出发的事件。

隧道：最初将在元素树的根处调用事件处理程序。随后，路由事件将朝着路由事件的源节点元素（即引发路由事件的元素）方向，沿路由线路传播到后续的子元素。在合成控件的过程中通常会使用或处理隧道路由事件，这样，就可以有意地禁止显示复合部件中的事件，或者将其替换为特定于整个控件的事件。在 WPF 中提供的输入事件通常是以隧道/冒泡对实现的。隧道事件有时又称作 Preview 事件，这是由隧道/冒泡对所使用的命名约定决定的。

事件首先是从根元素上被触发，然后从每一个元素向下沿着树传递，直到到达源元素为止（或者直到到达处理程序把事件标记为已处理为止）

他的执行方式正好与冒泡式的相反。

例子：

还是上面的代码，只需要修改xaml

XAML 

<Window x:Class="Wpfceshi.Window1"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="Window1" Height="300" Width="300" PreviewMouseDown="Window_PreviewMouseDown"  >

    <Grid PreviewMouseDown="Grid_PreviewMouseDown" x:Name="grid">

        <Button Height="30" Width="100" Content="点击我" PreviewMouseDown="Button_PreviewMouseDown"/>

    </Grid>

</Window>

特别值得注意的是：管道事件按照惯例,他们的名字中都有一个preview前缀，一般来说管道事件都有他的配对的冒泡事件，例如：PreviewMouseDown和MouseDown就是配对事件，如果同时存在的话，那么就会先执行管道事件然后才执行配对的冒泡事件。

为什么使用路由事件？ 
作为应用程序开发人员，您不需要始终了解或关注正在处理的事件是否作为路由事件实现。路由事件具有特殊的行为，但是，如果您在引发该行为的元素上处理事件，则该行为通常会不可见。

如果您使用以下任一建议方案，路由事件的功能将得到充分发挥：在公用根处定义公用处理程序、合成自己的控件或者定义您自己的自定义控件类。

路由事件侦听器和路由事件源不必在其层次结构中共享公用事件。任何 UIElement 或 ContentElement 可以是任一路由事件的事件侦听器。因此，您可以使用在整个工作 API 集内可用的全套路由事件作为概念“接口”，应用程序中的不同元素凭借这个接口来交换事件信息。路由事件的这个“接口”概念特别适用于输入事件。

路由事件还可以用来通过元素树进行通信，因为事件的事件数据会永存到路由中的每个元素中。一个元素可以更改事件数据中的某项内容，该更改将对于路由中的下一个元素可用。

之所以将任何给定的 WPF 事件作为路由事件实现，除了路由方面的原因，还有两个其他原因。如果您要实现自己的事件，则可能也需要考虑这两个因素：

某些 WPF 样式和模板功能（如 EventSetter 和 EventTrigger）要求所引用的事件是路由事件。前面提到的事件标识符方案就是这样的。

路由事件支持类处理机制，类可以凭借该机制来指定静态方法，这些静态方法能够在任何已注册的实例程序访问路由事件之前，处理这些路由事件。这在控件设计中非常有用，因为您的类可以强制执行事件驱动的类行为，以防它们在处理实例上的事件时被意外禁止。

为路由事件添加和实现事件处理程序 
若要在 XAML 中添加事件处理程序，只需将相应的事件名称作为一个属性添加到某个元素中，并将该属性的值设置为用来实现相应委托的事件处理程序的名称，如下面的示例中所示。

 

RoutedEventHandler 是基本的路由事件处理程序委托。对于针对某些控件或方案而专门处理的路由事件，要用于路由事件处理程序的委托还可能会变得更加专用化，因此它们可以传输专用的事件数据。例如，在常见的输入方案中，可以处理 DragEnter 路由事件。您的处理程序应当实现 DragEventHandler 委托。借助更具体的委托，可以对处理程序中的 DragEventArgs 进行处理，并读取 Data 属性，该属性中包含拖动操作的剪贴板内容。

在用代码创建的应用程序中为路由事件添加处理程序非常简单。路由事件处理程序始终可以通过帮助器方法 AddHandler 来添加，现有支持为 add 调用的也是此方法。但是，现有的 WPF 路由事件通常借助于支持机制来实现 add 和 remove 逻辑，这些逻辑允许使用特定于语言的事件语法来添加路由事件的处理程序，特定于语言的事件语法比帮助器方法更直观。下面是帮助器方法的示例用法：

 

如果使用的是 Visual Basic，则还可以使用 Handles 关键字，将处理程序作为处理程序声明的一部分来添加。

“已处理”概念
所有的路由事件都共享一个公用的事件数据基类 RoutedEventArgs。RoutedEventArgs 定义了一个采用布尔值的 Handled 属性。Handled 属性的目的在于，允许路由中的任何事件处理程序通过将 Handled 的值设置为 true 来将路由事件标记为“已处理”。处理程序在路由路径上的某个元素处对共享事件数据进行处理之后，这些数据将再次报告给路由路径上的每个侦听器。

Handled 的值影响路由事件在沿路由线路向远处传播时的报告或处理方式。在路由事件的事件数据中，如果 Handled 为 true，则通常不再为该特定事件实例调用负责在其他元素上侦听该路由事件的处理程序。这条规则对以下两类处理程序均适用：在 XAML 中附加的处理程序；由语言特定的事件处理程序附加语法（如 += 或 Handles）添加的处理程序。对于最常见的处理程序方案，如果将 Handled 设置为 true，以此将事件标记为“已处理”，则将“停止”隧道路由或冒泡路由，同时，类处理程序在某个路由点处处理的所有事件的路由也将“停止”。

但是，侦听器仍可以凭借“handledEventsToo”机制来运行处理程序，以便在事件数据中的 Handled 为 true 时响应路由事件。换言之，将事件数据标记为“已处理”并不会真的停止事件路由。您只能在代码或 EventSetter 中使用 handledEventsToo 机制：

在代码中，不使用适用于一般 CLR 事件的特定于语言的事件语法，而是通过调用 WPF 方法 AddHandler(RoutedEvent, Delegate, Boolean) 来添加处理程序。使用此方法时，请将 handledEventsToo 的值指定为 true。

在 EventSetter 中，请将 HandledEventsToo 属性设置为 true。

除了 Handled 状态在路由事件中生成的行为以外，Handled 概念还暗示您应当如何设计自己的应用程序和编写事件处理程序代码。可以将 Handled 概念化为由路由事件公开的简单协议。此协议的具体使用方法由您来决定，但是需要按照如下方式来对 Handled 值的预期使用方式进行概念设计：

如果路由事件标记为“已处理”，则它不必由该路由中的其他元素再次处理。

如果路由事件未标记为“已处理”，则说明该路由中前面的其他侦听器已经选择了不注册处理程序，或者已经注册的处理程序选择不操作事件数据并将 Handled 设置为 true。（或者，当前的侦听器很可能就是路由中的第一个点。） 当前侦听器上的处理程序现在有三个可能的操作方案：

不执行任何操作；该事件保持未处理状态，该事件将路由到下一个侦听器。

执行代码以响应该事件，但是所执行的操作被视为不足以保证将事件标记为“已处理”。该事件将路由到下一个侦听器。

执行代码以响应该事件。在传递到处理程序的事件数据中将该事件标记为“已处理”，因为所执行的操作被视为不足以保证将该事件标记为“已处理”。该事件仍将路由到下一个侦听器，但是，由于其事件数据中存在 Handled=true，因此只有 handledEventsToo 侦听器才有机会调用进一步的处理程序。

这个概念设计是通过前面提到的路由行为来加强的：即使路由中前面的处理程序已经将 Handled 设置为 true，也会增加为所调用的路由事件附加处理程序的难度（尽管仍可以在代码或样式中实现这一目的）。

有关 Handled、路由事件的类处理的更多信息，以及针对何时适合将路由事件标记为 Handled 的建议，请参见将路由事件标记为已处理以及类处理。

在应用程序中，相当常见的做法是只针对引发冒泡路由事件的对象来处理该事件，而根本不考虑事件的路由特征。但是，在事件数据中将路由事件标记为“已处理”仍是一个不错的做法，因为这样可以防止元素树中位置更高的元素也对同一个路由事件附加了处理程序而出现意外的副作用。

类处理程序 
如果您定义的类是以某种方式从 DependencyObject 派生的，那么对于作为类的已声明或已继承事件成员的路由事件，还可以定义和附加一个类处理程序。每当路由事件到达其路由中的元素实例时，都会先调用类处理程序，然后再调用附加到该类某个实例的任何实例侦听器处理程序。

有些 WPF 控件对某些路由事件具有固有的类处理。路由事件可能看起来从未引发过，但实际上正对其进行类处理，如果您使用某些技术的话，路由事件可能仍由实例处理程序进行处理。同样，许多基类和控件都公开可用来重写类处理行为的虚方法。

WPF 中的附加事件 
XAML 语言还定义了一个名为“附加事件”的特殊类型的事件。使用附加事件，可以将特定事件的处理程序添加到任意元素中。正在处理该事件的元素不必定义或继承附加事件，可能引发这个特定事件的对象和用来处理实例的目标也都不必将该事件定义为类成员或将其作为类成员来“拥有”。

WPF 输入系统广泛地使用附加事件。但是，几乎所有的附加事件都是通过基本元素转发的。输入事件随后会显示为等效的、作为基本元素类成员的非附加路由事件。例如，通过针对该 UIElement 使用 MouseDown（而不是在 XAML 或代码中处理附加事件语法），可以针对任何给定的 UIElement 更方便地处理基础附加事件 Mouse..::.MouseDown。

XAML 中的限定事件名称 
为子元素所引发的路由事件附加处理程序是另一个语法用法，它与类型名称.事件名称 附加事件语法相似，但它并非严格意义上的附加事件用法。可以向公用父级附加处理程序以利用事件路由，即使公用父级可能不将相关的路由事件作为其成员也是如此。请再次考虑下面的示例：

输入事件的冒泡和隧道
 
事件的处理顺序如下所示：

针对根元素处理 PreviewMouseDown（隧道）。

针对中间元素 1 处理 PreviewMouseDown（隧道）。

针对源元素 2 处理 PreviewMouseDown（隧道）。

针对源元素 2 处理 MouseDown（冒泡）。

针对中间元素 1 处理 MouseDown（冒泡）。

针对根元素处理 MouseDown（冒泡）。

路由事件处理程序委托提供对以下两个对象的引用：引发该事件的对象以及在其中调用处理程序的对象。在其中调用处理程序的对象是由 sender 参数报告的对象。首先在其中引发事件的对象是由事件数据中的 Source 属性报告的。路由事件仍可以由同一个对象引发和处理，在这种情况下，sender 和 Source 是相同的（事件处理示例列表中的步骤 3 和 4 就是这样的情况）。

由于存在隧道和冒泡，因此父元素接收 Source 作为其子元素之一的输入事件。当有必要知道源元素是哪个元素时，可以通过访问 Source 属性来标识源元素。

通常，一旦将输入事件标记为 Handled，就将不进一步调用处理程序。通常，一旦调用了用来对输入事件的含义进行特定于应用程序的逻辑处理的处理程序，就应当将输入事件标记为“已处理”。

对于这个有关 Handled 状态的通用声明有一个例外，那就是，注册为有意忽略事件数据 Handled 状态的输入事件处理程序仍将在其路由中被调用。

通常，隧道事件和冒泡事件之间的共享事件数据模型以及先引发隧道事件后引发冒泡事件等概念并非对于所有的路由事件都适用。该行为的实现取决于 WPF 输入设备选择引发和连接输入事件对的具体方式。实现自己的输入事件是一个高级方案，但是您也可以选择针对自己的输入事件遵循该模型。

一些类选择对某些输入事件进行类处理，其目的通常是重新定义用户驱动的特定输入事件在该控件中的含义并引发新事件。

EventSetter 和 EventTrigger 
在样式中，可以通过使用 EventSetter 在标记中包括某个预先声明的 XAML 事件处理语法。在应用样式时，所引用的处理程序会添加到带样式的实例中。只能针对路由事件声明 EventSetter。下面是一个示例。请注意，此处引用的 b1SetColor 方法位于代码隐藏文件中。

 

请注意 aqua: 前缀；该前缀在本例中是必需的，因为附加事件是来自自定义映射 xmlns 的自定义事件。

如何在 WPF 中实现附加事件 
在 WPF 中，附加事件由 RoutedEvent 字段来支持，并在引发后通过元素树进行路由。通常，附加事件的源（引发该事件的对象）是系统或服务源，所以运行引发该事件的代码的对象并不是元素树的直接组成部分。

附加事件的方案 
在 WPF 中，附加事件存在于具有服务级抽象的某些功能区域，例如，对于通过静态 Mouse 类或 Validation 类实现的事件。与服务交互或使用服务的类可以在附加事件语法中使用该事件，也可以选择将附加事件作为路由事件来实现（这是类如何集成服务功能的一部分）。

尽管 WPF 定义了许多附加事件，但您直接使用或处理附加事件的方案却很有限。一般情况下，附加事件用于实现体系结构目的，但随后即被转发给非附加（使用 CLR 事件“包装”提供支持）路由事件。

例如，通过针对该 UIElement 使用 MouseDown（而不是在 XAML 或代码中处理附加事件语法），可以针对任何给定的 UIElement 更方便地处理基础附加事件 Mouse..::.MouseDown。附加事件用于实现体系结构目的，因为它允许进一部扩展输入设备。假设的设备只需引发 Mouse..::.MouseDown 即可模拟鼠标输入，而不需要从 Mouse 派生。但是，此方案会涉及事件的代码处理，而附加事件的 XAML 处理则与此方案无关。

在 WPF 中处理附加事件 
处理附加事件的过程以及您将要编写的处理程序代码与路由事件基本相同。

一般情况下，WPF 附加事件与 WPF 路由事件并没有太大的区别。不同之处在于如何确定事件的源，以及如何通过类将事件作为成员进行公开。（这还将影响 XAML 处理程序语法。）

但是，正如前文所述，现有的 WPF 附加事件并不是专门用于在 WPF 中进行处理。该事件的目的常常是实现合成元素，以便向合成中的父元素报告某个状态，在这种情况下，该事件常常在代码中引发，并且还依赖于相关父类中的类处理。例如，Selector 中的项应引发附加的 Selected 事件，该事件随后将由 Selector 类进行类处理，然后可能由 Selector 类转换为不同的路由事件 SelectionChanged。

将您自己的附加事件定义为路由事件 
如果您从通用 WPF 基类派生，则可以通过在类中包括某些模式方法并使用基类中已经存在的实用工具方法来实现您自己的附加事件。

模式如下：

带有两个参数的方法 Add*Handler。第一个参数必须标识事件，而标识的事件必须与方法名称中带有 * 的名称相匹配。第二个参数是要添加的处理程序。该方法必须是公共且静态的，没有任何返回值。

带有两个参数的方法 Remove*Handler。第一个参数必须标识事件，而标识的事件必须与方法名称中带有 * 的名称相匹配。第二个参数是要移除的处理程序。该方法必须是公共且静态的，没有任何返回值。

当针对某个元素声明附加事件处理程序属性时，Add*Handler 访问器方法可以加快 XAML 处理。Add*Handler 和 Remove*Handler 方法还可实现对附加事件的事件处理程序存储区的代码访问。

这个普通模式对于框架中的实际实现还不够精确，因为任何给定的 XAML 读取器实现都可能采用不同的架构在支持语言和体系结构中标识基础事件。这是 WPF 将附加事件作为路由事件来实现的原因之一；用于事件的标识符 (RoutedEvent) 已经由 WPF 事件系统进行定义。而且，路由一个事件也是对附加事件的 XAML 语言级概念的自然实现扩展。

WPF 附加事件的 Add*Handler 实现包括将路由事件和处理程序用作参数来调用 AddHandler。

此实现策略和路由事件系统一般将附加事件的处理限制为 UIElement 派生类或 ContentElement 派生类，因为只有这些类才具有 AddHandler 实现。

例如，下面的代码按照 WPF 将附加事件作为路由事件进行声明的附加事件策略为所有者类 Aquarium 定义 NeedsCleaning 附加事件。

<img class="fit-image" "="" src="http://new.51cto.com/files/uploadimg/20080828/095744724.jpg" width="728" border="0" style="margin: 0px; padding: 0px; border: 0px;"> 

请注意，用来确定附加事件标识符字段的方法 RegisterRoutedEvent 实际上与用来注册非附加路由事件的方法相同。附加事件和路由事件都是在集中管理的内部存储区中进行注册的。此事件存储区实现则实现了路由事件概述中讨论的“事件作为界面”概念方面的注意事项。

引发 WPF 附加事件 
通常不需要从代码中引发 WPF 定义的现有附加事件。这些事件采用一般的“服务”概念模型，而服务类（如 InputManager）则负责引发事件。

但是，如果您根据将 RoutedEvent 作为附加事件基础的 WPF 模型来定义自定义附加事件，则可以使用 RaiseEvent 从任何 UIElement 或 ContentElement 中引发附加事件。引发路由事件（不管是否附加）要求您在元素树中声明一个特定的元素作为事件源；该事件源被报告为 RaiseEvent 调用方。您的服务负责决定将哪个元素报告为元素树中的事件源。