WPF隧道，實際使用？

Question

什麼樣的實際場景需要使用隧道事件？

我知道一個模糊的答案，可能是因爲當我們想要在引發事件的視覺/邏輯上處理事件時使用它。但這只是理論。

在實踐中，爲什麼我應該隧道事件？

隧道（和冒泡）也可以跨邏輯樹或可視樹或兩者工作嗎？

Answer 1

我發現隧道事件對於處理我沒有創建自己的元素上的事件非常有用，因此沒有簡單的方法來添加事件處理程序。例如，ItemsControl基於模板生成UI元素，因此，獲取對這些元素的引用並不總是一個簡單的過程。而不是爲ItemsControl生成的每個項目添加事件處理程序，而是可以在單個父元素上處理隧道事件。

路由事件traverse a 'hybrid' tree，它既不是視覺樹也不是邏輯樹。這聽起來有點瘋狂，但它從來沒有造成我過去的問題。

Answer 2

隧道事件在WPF中用於所有的OnPreview事件。如果你想讓實際的目標元素成爲接收事件的最後一個元素，隧道是有意義的。

如果您有包含文本框的項目的列表框。單擊文本框將消耗點擊，因此不選擇列表框。如果您使用隧道或預覽鼠標單擊事件，則可以先選擇，然後將其保留爲未處理狀態，然後移至文本框。還要注意，在WPF中，如果預覽事件未處理，則每個事件都將首先發出預覽，然後是一個氣泡事件。

MSDN：

隧道：最初，事件處理程序 在元件樹根被調用。然後 路由事件通過連續的子元素 沿着途徑，對節點 元素是路由事件 源（即上調 路由事件的元件）行進的路線 。隧道路由事件 經常使用或作爲其一部分 處理的合成爲一個控制，例如 從複合部件事件可以 故意抑制或由特定於所述 完全控制事件替換 。 WPF中提供的輸入事件 經常作爲隧道/冒泡對實現 。 隧道事件有時也被稱爲預覽事件 ，因爲 命名約定的 用於配對。

AFAIK可視化樹用於遍歷，但由於MSDN關閉，我無法尋找適當的來源。

Answer 3

這是一個引自MSDN：

隧道：最初，事件處理程序 在元件樹根被調用。然後 路由事件通過連續的子元素 沿着途徑，對節點 元素是路由事件 源（即上調 路由事件的元件）行進的路線 。隧道路由事件 經常使用或作爲其一部分 處理的合成爲一個控制，例如 從複合部件事件可以 故意抑制或由特定於所述 完全控制事件替換 。 WPF中提供的輸入事件 經常作爲隧道/冒泡對實現 。 隧道事件有時也被稱爲預覽事件 ，因爲 命名約定的 用於配對。

隧道事件是什麼就是俗稱的Preview -events。

你也可能想在Advanced WPF: Understand Routed Events and Commands in WPF閱讀此MSDN文章。 @Robert Havery wrote a good explenation to a similar question here on SO.

Answer 4

用戶交互通常由事件對錶示 - 一個預覽交互（隧道）和一個對它作出反應（冒泡）的事件。讓隧道「預覽」事件首先允許父控件攔截交互。例如，如果要創建自己的按鈕樣式用戶控件，則控件的一部分可能是圖標。如果用戶點擊圖標，您將截取隧道點擊預覽事件，因爲該圖標不需要知道它已被點擊。然後，您可以引發一個冒泡事件，通知包含您的按鈕的任何控件它已被點擊。