在實用WPF時，一般情況下都會碰到有關WPF事件的相關應用。那么首先我們需要了解的就是一些獲得支持的WPF事件策略。其中主要包括三種WPF事件策略：#t#

Tunneling：事件首先在根元素激發，然后到達樹下的每個元素直到源元素（或者有處理函數處理這個事件終止了傳遞）。

Bubbling：事件首先在源元素激發，然后向上直到根元素（或者有處理函數處理這個事件終止了傳遞。

Direct：事件只在源元素激發。這與普通的.NET事件一樣，除了參與事件觸發器。

在上面的WPF事件策略例子中，我們注冊的事件策略就是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同時定義。這種行為有什么好處呢？

看下面的一個WPF事件策略例子：比如，我們想實現一種特殊的編輯框，只允許輸入一些特定的字符。以前的實現方法在處理編輯框的KeyDown或者編輯框的WM_CHAR事件，然后判斷新輸入的字符是否滿足條件，如果不滿足，我們再把編輯框的值設置為原來的值。這種實現技術會有字符的一個回退過程。而在WPF中，實現方法不同，直接在PrevewKeyDown等Tunneling事件中處理，如果是不需要的字符，把事件設置為已經處理過。

這樣這個事件就不會進入到后面的Bubbling事件KeyDown中，WPF也根本不會顯式這個字符。這種方法的效果將比之前的回退處理好很多。

雖然我們可以通過RoutedEventArgs參數的Handled屬性為True來終止事件的傳遞。但是，有時候我們需要某個事件始終被接受處理，這可以通過程序代碼實現。使用重載的AddHanlder方法。比如，我們給窗口添加一個鼠標右鍵的處理方法（其中MRBD_Handler是類的一個事件方法）：
 

public AboutDialog() {   
InitializeComponent();   
this.AddHandler(Window.
MouseRightButtonDownEvent, 
new MouseButtonEventHandler
(MRBD_Handler), true);   
} 

這樣，任何條件下，MRBD_Handler都可以接收到窗口的鼠標右鍵事件。即使鼠標右鍵是點擊在窗口中的某個子控件之上。

以上就是對WPF事件策略的一些相關介紹。