Routed Events in Silverlight

With the Windows Presentation Foundation a new type of events were introduced - the RoutedEvents. They have provided the developer with entirely new approach to the eventing and the event handling. Those of you who are already at the WPF and have experience with the routing of events may found this article useless, but I believe that it can be a good starting point for everyone who makes his first steps in the event routing and more specially in the Silverlight event routing.

Routed events basics

Before explaining the routed events you have to understand the element tree (also known as visual tree), that is typical for every WPF or Silverlight application. It consists of the controls hosted by the application and their parent-child relationships. For example:

UserControl>

    Grid>

        StackPanel>

            TextBlock />

            TextBox />

            Button />

        StackPanel>

    Grid>

UserControl>

The routed events are directly connected with the visual tree. It is used to propagate the event upwards or downwards on it, so the event could be handled by controls that are different then the control that originally raised the event.

There are three types of RoutedEvents - direct, tunneling, and bubbling.

Direct

This type of routed events can be handled only by the controls that had raised them. They are very similar to the events we are familiar with from WinForms and ASP.NET.

Tunneling

By this type of events, first the handlers of the root element of the visual tree are invoked and then the event travels through the child elements till it reaches the one that originally has raised it.

Bubbling

This type of events is first handled by their source and then the event handlers of the parent elements are invoked till the event reaches the root element of the visual tree.

The Handled property

Another basic thing is that the event arguments of every routed event have a Handled property. When set to true in the event handler the event won't propagate further in the visual tree.

RoutedEvents in Silverlight

The things explained above are fully in force for WPF, but for the Silverlight they are a little bit different. There are some differences between the routed events in Silverlight and WPF. Here are the most important of them:

You cannot create custom RoutedEvents in Silverlight. In WPF to create a custom event of this type we use EventManager, but in Silverlight it's not available. There still is a way out, but we'll discuss it later on in the article.

The only type of routed events in Silverlight is the bubbling event. Such events for example are the MouseLeftButtonDown and the MouseLeftButtonUp.

The control specific events don't bubble - for example the Click event of the Button control. This one sounds pretty logical - why to propagate an event through visual tree, when it can be handled only by a specific type of controls?

Here is a simple example (with source code) that will illustrate the behavior of the bubbling events in Silverlight. For it I have used the MouseLeftButtonUp and MouseLeftButtonDown events.

When I handle the MouseLeftButtonUp I write the name of the control that had handled it in the list and on MouseLeftButtonDown I clear the list. In the handlers of the ListBox for these two events I set the handled property to true, because I don't want the events raised by this control to be handled further in the visual tree. The same I have done with the handler for the MouseLeftButtonDown event - I need to clear the list once.

Note! Use the routed events where needed and be sure to stop the events you don't need to propagate through the visual tree, because this might cause faults and malfunctions in your application. For example the LayoutRoot is listening for an event that is raised in a specific part of the tree (the rectangle), but the event can also be raised in other parts of the tree (the ListBox).If we let the event, raised by the ListBox, to propagate to the LayoutRoot, the last will handle it, which causes the incorrect behaviour of the application.

The Article Was Taken from Here