浅谈wpf中的路由事件

路由事件简介

　　谈到路由事件，我想首先我们就需要问自己一个问题。在.net已经支持事件的情况下，为什么WPF还额外提供了对路由事件的支持？这是因为在WPF开发模型下，原始的CLR事件已经不能满足开发的要求，从而导致对事件的处理异常繁琐：

　　首先就是控件的封装。WPF中，我们可以将一个控件作为另一个控件的子控件，从而呈现丰富的效果。例如我们可以在一个Button中包含一个图像。在这种情况下，对图像的点击实际上应该是对按钮的点击。正因为如此，我们期望真正触发被点击事件的控件是Button，而不是嵌在其中的图像。这正好要求WPF将点击事件沿视觉树依次传递，即路由事件的路由功能。可以说，这是WPF添加路由事件的最直观理由。

　　同样由于WPF提供了丰富的组合模型，一小块程序界面组成中就可能包含了多个相同的界面元素。为了能在一处执行对特定事件的侦听，而不是为这些界面组成依次添加事件处理函数。路由事件为这种情况提供了一种较为简单的处理方式：在它们的公共父元素中添加事件处理函数。在该路由事件路由到该元素时，事件处理函数才会被调用。例如在为TreeView中为DragDrop功能提供支持的时候，您不可能在各个条目中依次标明对鼠标操作的响应，而应在TreeView元素中侦听鼠标操作事件。

　　除了这些较为明显的优点之外，路由事件还提供了更为丰富的功能。首先，路由事件允许软件开发人员通过EventManager.RegisterClassHandler()函数使用由类定义的静态处理程序。这个类定义的静态处理程序与类型的静态构造函数有些类似：在路由事件到达路由中的元素实例时，WPF都会首先调用该类处理程序，然后再执行该实例所注册的侦听函数。这种控件编写方式在WPF的内部实现中经常使用。另外，通过对路由事件进行管理的类型EventManager，我们可以通过函数调用GetRoutedEvents()得到相应的路由事件，而不再需要运用反射等较为耗时的方法。

　　路由事件一般使用以下三种路由策略：1) 冒泡：由事件源向上传递一直到根元素。2) 直接：只有事件源才有机会响应事件。3) 隧道：从元素树的根部调用事件处理程序并依次向下深入直到事件源。一般情况下，WPF提供的输入事件都是以隧道/冒泡对实现的。隧道事件常常被称为Preview事件。

　　您可能会想，路由事件的直接路由方式与普通CLR事件的处理方式有什么不同呢？实际上并没有什么不同。但是路由事件为WPF提供了更好的支持。例如触发器等功能需要事件是路由事件。同时路由事件还提供了类处理机制，从而为WPF提供了更灵活的执行方式。在后面的章节中，您将看到WPF是如何通过类处理函数完成一些WPF常见功能的。

Linux内核更多免费文档,面试资料,教程视频加qqun：891587639获取资源

 </