WPF Quick guide for events in 10:WPF and differences between bubbling events and tunneling events (preview events)

This article summarizes:

1: What is a routed event;

2: Interrupt event routing;

3: Custom routed event;

4: Why a custom routed event is required;

5: What are bubbling events and preview events (tunneling events);

1: What is a routed event

The events in WPF are routed events, called routed events, and MSDN is defined as follows:

Feature definition: A routed event is an event that can invoke handlers on multiple listeners in the element tree instead of just the object that raised the event.

Implementation definition: A routed event is a CLR event that can be supported by an instance of the RoutedEvent class and handled by the Windows Presentation Foundation (WPF) event System.

But both of these definitions are abstract, and we look at more specific definitions:

       <border height= "width=" borderbrush= "Gray" borderthickness= "1" >            <stackpanel background= " Lightgray "orientation=" horizontal "mouseup=" Stackpanel_mouseup ">                <textblock name=" YesTB "Width=" 50 "  mouseup= "Yestb_mouseup" background= "Blue" >Yes</TextBlock>            </StackPanel>        </border >

In this example, the event routes for the events are:

TextBlock-->stackpanel-->border->

2: Interrupt Event routing
All routed events share a common event data base class, RoutedEventArgs. RoutedEventArgs defines a Handled attribute that takes a Boolean value. The purpose of the Handled property is to allow any event handlers in the route to mark routed events as handled by setting the value of Handled to true.

        private void Stackpanel_mouseup (object sender, MouseButtonEventArgs e)        {            MessageBox.Show ("Panel");        }        private void Yestb_mouseup (object sender, MouseButtonEventArgs e)        {            MessageBox.Show ("button");            E.handled = true;        }

In the example above, the Stackpanel_mouseup event is no longer triggered.

3: Custom routed event

As shown in the following example, first register a RoutedEvent with the Registerroutedevent method. By convention, RoutedEvent static field names should end with the suffix Event . In this example, the name of the event is Tap, and the event's routing policy is Bubble. After the call is registered, you can provide a common language runtime (CLR) event accessor for the event to be added and removed.

Note that although the event is raised by the OnTap virtual method in this particular example, how you raise the event or how the event responds to changes depends on your needs.

      Also note that this example primarily implements an entire subclass of Button, which is built as a separate assembly and then instantiated as a custom class on a separate Extensible Application Markup Language (XAML) page. This is to illustrate the notion that a control that creates subclasses can be inserted into a tree made up of other controls, in which case the custom events on those controls have the exact same event routing functionality as any inherent Windows Presentation Foundation (WPF) element.

 public class mybuttonsimple:button{//Create a custom routed event by first registering a routedeventid//Th Is event uses the bubbling routing strategy public static readonly RoutedEvent tapevent = Eventmanager.registerroutedev    ENT ("Tap", Routingstrategy.bubble, typeof (Routedeventhandler), typeof (Mybuttonsimple)); Provide CLR accessors for the event public event Routedeventhandler Tap {add {AddHandler (tapevent, V Alue);    } remove {RemoveHandler (tapevent, value);} }//This method raises the Tap event void Raisetapevent () {RoutedEventArgs Neweventargs = new Routed            EventArgs (mybuttonsimple.tapevent);    RaiseEvent (Neweventargs); }//For demonstration purposes we raise the event when the mybuttonsimple is clicked protected override void Onclic    K () {raisetapevent (); }}

<window      xmlns= "http://schemas.microsoft.com/winfx/2006/xaml/presentation"    xmlns:x= "http// Schemas.microsoft.com/winfx/2006/xaml "    xmlns:custom=" Clr-namespace:sdksample;assembly=sdksamplelibrary "    x:class= "Sdksample.routedeventcustomapp"    >    <Window.Resources>      <style targettype= "{ X:type Custom:mybuttonsimple} ">        <setter property=" Height "value="/> <setter property=        "Width "Value="/>        <setter property= "HorizontalAlignment" value= "left"/>        <setter property= " Background "value=" #808080 "/>      </Style>    </Window.Resources>    <stackpanel background= "Lightgray" >        <custom:mybuttonsimple name= "mybtnsimple" tap= "Taphandler" >Click to see Tap Custom Event work</custom:mybuttonsimple>    </StackPanel></Window>

4: Why custom routed events are required

Until now it seems that we do not need custom routed events. However, when we create custom controls, it is necessary to create some and business-related routed events.

For example, to create a task display control in an online exam, you can design a custom event for the control, which is "submit." In this way, this is not only a few common events, but it can also look more "business".

5: What are bubbling events and preview events (tunneling events)

routed events are actually divided into two categories: bubbling events and Preview events (tunneling events). The example above is the bubbling event.

The bubbling event is the most common in a WPF routed event, which indicates that an event is diffused (propagated) from the source element to the visual tree until it is processed or reached the root element. This allows you to handle events on the top level objects of the source element. For example, you can attach an Button.Click handler to an embedded Grid element instead of attaching it directly to the button itself. A bubble event has a name that indicates its operation (for example, MouseDown).

Tunneling events take another approach, starting with the root element and traversing the element tree down until the source element of the event is processed or reached. This allows the upstream element to intercept and process the event before it reaches the source element. According to the naming convention, tunnel events are prefixed with Preview (for example, PreviewMouseDown).

In the example at the beginning of this article, if we change the MouseUp to PreviewMouseUp, what will the effect be?

difference:

Bubbling event: Click on Yestb, First "button" pops up, then "Panel".

Preview Event (tunneling event) Event: Click on Yestb, First "Panel" pops up, then "button".

See this difference, then we join E. The timing of the handled=true will be different. First of all

In the Bubbling event Example: E. Handled=true add in Yestb_previewmouseup, after adding, click Yestb, will only pop up "button".

Preview Event (tunnel event) in the example: E. Handled=true home in Stackpanel_previewmouseup, after joining, click Yestb, will only pop up "Panel".

WPF Quick guide for events in 10:WPF and differences between bubbling events and tunneling events (preview events)