Routed Events in Silverlight

Referred URL - http://www.silverlightshow.net/items/Routed-Events-in-Silverlight.aspx

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>

Don't Miss

• Silverlight Toolkit Overview
  
• Attached Properties in Silverlight
  
• Tip: How to declare a dependency property in Silverlight?
  
• Asynchronous Silverlight - Execute on the UI thread

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 useEventManager, 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 theMouseLeftButtonDown 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 onMouseLeftButtonDown 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.

Telerik RadControls for Silverlight and the EventManager

If you didn't know, the Telerik RadControls for Silverlight implement routed events in the way they are in WPF. Almost all of the events used there are RoutedEvents and maybe you'll ask how they made custom RoutedEvents, when Silverlight doesn't support creation of custom RoutedEvents? To overcome the limitation they introduce the EventManager,RoutedEvent and RoutingStrategy types in their controls. Those who are familiar with WPF won't be surprised to see these three here. The functionality from the WPF is mirrored exactly the same, so the use in Silverlight is identical. If you have the RadControls at hand and need your application to support custom routed events you can find a great use of them. You can read more about that in Hristo Hristov’s post.

Conclusion

The routed events are a very powerful mechanism that can improve the functionality of our applications a lot. There are some differences between their appearance in Silverlight and WPF, but let's don't forget that Silverlight is a subset of WPF and it still has a long way to go. But I was pretty impressed by the bubbling events and I will surely find them useful for my future development.