传递事件
WPF
在
.NET
简单事件通知之上添加了很多基础结构。传递事件的设计使得事件可以与元素树一起很好的工作。事件发生后,可以在视觉树和逻辑树自动地进行上下传递,我们不需要添加任何额外的代码。
传递事件使得我们不需要过多关注于视觉树,这样封装对于我们理解
WPF
的元素合成非常重要。比如,我们点击一个按钮的事件,在点击的时候我们实际上点击的
是一个
ButtonChrome
或者
TextBlock
,也就是说我们点击的是
Button
的内容元素。正是因为事件可以沿视觉树传递,
Button
才发
现这个事件,并且可以处理。因此,我们可以给
Button
的
Content
当中添加任意的元素,而不会对事件有任何的影响。如果没有这样的事件传递,我们
点击
Button
内的元素时,必须手动编写代码触发
Button
点击事件。
传递事件的的实现和行为与
Dependency
属性类似。同样,我们看看如何实现简单的传递事件。多数时候,传递事件并不比普通的
.NET
事件难。与
Dependency
属性一样,
.NET
语言(除了
XAML
)本身并不明白传递目标。这些支持都是基于
WPF API
。
从上面的实现可以看出,事件与
Dependency
属性有很多相似之处。也是定义一个静态的
RoutedEvent
成员,同样在静态构造函数里注册事件。
为了方便,也包装了一个普通的
.NET
事件。这里的
AddHandler/RemoveHandler
不是从
DependencyObject
派生,而是更高一级的基类
System.Windows.UIElement
。这两个方法为相应的事件添加
/
删除一个委派。在
OnMouseLeftButtonDown
中,我们构造一个事件参数,传入事件源对象
this
,然后调用
RaiseEvent
函数。
事件策略和处理函数
注册
WPF
事件时,我们需要为传递事件选择一种策略,这个策略指定了事件在元素树中传递的方式。
WPF
支持这样三种策略:
Tunneling
:事件首先在根元素激发,然后到达树下的每个元素直到源元素(或者有处理函数处理这个事件终止了传递)。
Bubbling
:事件首先在源元素激发,然后向上直到根元素(或者有处理函数处理这个事件终止了传递)。
Direct
:事件只在源元素激发。这与普通的
.NET
事件一样,除了参与事件触发器。
在上面的例子中,我们注册的事件策略就是
Bubbling
。
传递事件的处理函数的参数与普通
.NET
事件一样。第一个参数
System.Object
表示处理函数依附的元素。第二个的
System.EventArgs
派生类,提供了如下四个有用的属性:
Source
:逻辑树中激发事件的原始元素。
OriginalSource
:视觉树中激发事件的原始元素。
Handled
:布尔值,表示事件是否被处理。
RoutedEvent
:实际的传递事件对象(比如
Button.ClickEvent
)。这个对于相同的处理函数处理多个传递事件时非常有用,可以用来区别传递事件。
Source
和
OriginalSource
代表了逻辑树和视觉树对象。这有利于我们进行一些低级控制,但是对于有的事件,不需要区别它们,这两个的值是相同的。
现在,我们看看
WPF
到底是如何处理
Bubbling
和
Tunneling
事件的。最后介绍了
Attached
事件。
在
UIElement
类,预定义了很多的传递事件,比如键盘、鼠标等等。其中大多数是
Bubbling
事件,其中很多的事件都还有一个对应的
Tunneling
事件。所有的
Tunneling
事件都是
Preview
前缀命名,它们都在对应的
Bubbling
事件之前激发。比如
PreviewMouseMove
这个
Tunneling
事件是在
MouseMove
这个
Bubbling
事件之前激发的。
Tunneling
事件的好处就是可以有机会改变或者取消后面的
Bubbling
事件。
WPF
内建的响应事件只会对
Bubbling
事件进行响应,当然,
前提了
Bubbling
和
Tunneling
同时定义。
这种行为有什么好处呢?看下面的一个例子:比如,我们想实现一种特殊的编辑框,只允许输入一些特定
的字符。以前的实现方法在处理编辑框的
KeyDown
或者编辑框的
WM_CHAR
事件,然后判断新输入的字符是否满足条件,如果不满足,我们再把编辑框的
值设置为原来的值。这种实现技术会有字符的一个回退过程。而在
WPF
中,实现方法不同,直接在
PrevewKeyDown
等
Tunneling
事件中处
理,如果是不需要的字符,把事件设置为已经处理过。这样这个事件就不会进入到后面的
Bubbling
事件
KeyDown
中,
WPF
也根本不会显式这个字
符。这种方法的效果将比之前的回退处理好很多。
虽然我们可以通过
RoutedEventArgs
参数的
Handled
属性为
True
来终止事件的传递。但是,有时候我们需要某个事件始终被接受处理,这可以通过程序代码实现。使用重载的
AddHanlder
方法。比如,我们给窗口添加一个鼠标右键的处理方法(其中
MRBD_Handler
是类的一个事件
方法):
这样,任何条件下,
MRBD_Handler
都可以接收到窗口的鼠标右键事件。即使鼠标右键是点击在窗口中的某个子控件之上。
Attached
事件
与 Attached 属性类似, WPF 的 Element 在事件没有定义的情况下也支持 Tunneling 或者 Bubbling 事件。比如,我们可以在一个简单的窗口程序中这样指定事件函数:
例子中,因为
Window
本身没有定义
Click
事件,所以我们必须指定
Click
事件属性的名称前缀,也就是定义事件的类名。经过这样的定义后,点击在
Window
中的
TestButton
,也会激发属性声明的
Click
事件,调用对应的
Button_Click
方法。
为什么这样的定义可以通过呢?首先编译时,
XAML
会看到
Button
类确实定义了一个
Click
的
.NET
事件。在运行时,会直接调用
AddHandler
把这两个事件依附到
Window
对应的类当中。所以上面用
XAML
属性声明的事件代码与下面的程序代码等效: