WPF Tunneling, practical use?

What practical scenarios need to use Tunneling of events?

I know a vague answer to this could be that it is used when we want to handle a event across the visual/logical o开发者_StackOverflow中文版n which event is raised. But that's just theory.

In practice why should I tunnel an event?

Also does tunneling (and bubbling) works across Logical tree or Visual tree or both?

I find tunneling events to be very useful for handling events on elements which I have not created myself, and hence have no easy way to add an event handler to. For example, the ItemsControl generates UI elements based on a template, as a result it is not always a straightforward process to get a reference to these elements. Rather than adding an event handler to each item which the ItemsControl generates you can instead handle the tunnelled event on a single parent element.

Routed events traverse a 'hybrid' tree, which is neither the visual or logical tree. This sounds a bit crazy, but it has never cause me problems in the past.

Tunnel events are used in WPF for all the OnPreview events. Tunneling makes sense if you want the actual targeted element to be the last that receives the event.

If you have a list box with an item which contains a textbox. Clicking the textbox will consume the click thus not selecting the list box. If you use the tunneled or preview mouse click event, you can select first, leaving it unhandled and then it travels to the text box. Also note that in WPF every event will first fire a preview then a bubble event, if the preview event was unhandled.

Msdn:

Tunneling: Initially, event handlers at the element tree root are invoked. The routed event then travels a route through successive child elements along the route, towards the node element that is the routed event source (the element that raised the routed event). Tunneling routed events are often used or handled as part of the compositing for a control, such that events from composite parts can be deliberately suppressed or replaced by events that are specific to the complete control. Input events provided in WPF often come implemented as a tunneling/bubbling pair. Tunneling events are also sometimes referred to as Preview events, because of a naming convention that is used for the pairs.

AFAIK the Visual tree is used for traversing, but because MSDN is down i can't look for a proper source.

This is a quote from MSDN:

Tunneling: Initially, event handlers at the element tree root are invoked. The routed event then travels a route through successive child elements along the route, towards the node element that is the routed event source (the element that raised the routed event). Tunneling routed events are often used or handled as part of the compositing for a control, such that events from composite parts can be deliberately suppressed or replaced by events that are specific to the complete control. Input events provided in WPF often come implemented as a tunneling/bubbling pair. Tunneling events are also sometimes referred to as Preview events, because of a naming convention that is used for the pairs.

Tunneling events are what is commonly known as Preview-events.

You might also want to read this MSDN Article on Advanced WPF: Understand Routed Events and Commands in WPF. @Robert Havery wrote a good explenation to a similar question here on SO.

User interactions are often represented by pairs of events - one that previews the interaction (tunneling) and one that reacts to it (bubbling). Having the tunneling "preview" event first allows the parent control to intercept the interaction.

As an example, if you were to create your own button style user control a part of the control might be an icon. If the user were to click the icon you would intercept the tunneling click preview event because the icon doesn't need to know it was clicked. You could then raise a bubbling event informing any controls containing your button that it had been clicked.