WPF隧道，实际使用？

Question

哪些实际场景需要使用事件隧道？

我知道一个模糊的答案可能是，当我们想要在引发事件的视觉/逻辑上处理事件时，可以使用它。但这只是理论上的。

在实践中，我为什么要对事件进行隧道操作？

隧道(和冒泡)是否可以跨逻辑树或Visual树工作，或者两者都能工作？

Answer 1

我发现隧道事件对于处理不是我自己创建的元素上的事件非常有用，因此没有简单的方法来添加事件处理程序。例如，ItemsControl基于模板生成UI元素，因此获取对这些元素的引用并不总是一个简单的过程。您可以在单个父元素上处理隧道事件，而不是向ItemsControl生成的每个项添加事件处理程序。

Routed events traverse a 'hybrid' tree，它既不是可视树，也不是逻辑树。这听起来有点疯狂，但它在过去从来没有给我带来过问题。

Answer 2

隧道事件在WPF中用于所有OnPreview事件。如果您希望实际的目标元素是最后一个接收事件的元素，则隧道机制是有意义的。

如果您有一个列表框，该列表框包含一个包含文本框的项。单击文本框将消耗单击，因此不会选择列表框。如果使用隧道鼠标单击事件或预览鼠标单击事件，则可以先选择，不对其进行处理，然后移动到文本框。还请注意，在WPF中，如果未处理预览事件，则每个事件都将首先触发预览，然后触发气泡事件。

Msdn：

隧道:最初，调用元素树根的事件处理程序。然后，被路由的事件通过沿着路由的连续的子元素向作为被路由的事件源的节点元素(引发被路由的事件的元素)传播。隧道路由的事件通常作为控件合成的一部分使用或处理，使得来自复合部分的事件可以被特定于整个控件的事件故意抑制或替换。WPF中提供的输入事件通常以隧道/冒泡对的形式实现。由于隧道对使用的命名约定，隧道事件有时也称为预览事件。

AFAIK Visual树用于遍历，但由于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.