(X) Hide this
    • Login
    • Join
      • Say No Bots Generate New Image
        By clicking 'Register' you accept the terms of use .

Routed Events in Silverlight

(5 votes)
Martin Mihaylov
>
Martin Mihaylov
Joined Oct 29, 2007
Articles:   50
Comments:   70
More Articles
8 comments   /   posted on Nov 27, 2008
Categories:   Patterns and Practices , General

This article is compatible with the latest version of 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.

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.

References

Hristo Hristov with his post about the EventManager included in the Telerik RadControls for Silverlight:

http://blogs.telerik.com/HristoHristov/Posts/08-07-23/Routed_Events_in_Silverlight_2.aspx

And the MSDN article about the RoutedEvents in WPF:

http://msdn.microsoft.com/en-us/library/ms742806(VS.85).aspx


Subscribe

Comments

  • -_-

    RE: Routed Events in Silverlight


    posted by DB on Feb 26, 2009 08:58

    "why to propagate an event through visual tree, when it can be handled only by a specific type of controls?"

    Easy: because in some cases, we need a parent control to have a generic handler for children events. For example, it is VERY useful to have a Panel which handle the click event of all the buttons it contains.

  • -_-

    RE: Routed Events in Silverlight


    posted by Anon on May 06, 2009 19:57
    Proof read your posts
  • -_-

    RE: Routed Events in Silverlight


    posted by Andrew Whiddett on May 15, 2009 17:02
    Check out http://sl3routedevents.codeplex.com/ - a free to use implementation of custom routed events for silverlight 3.
  • -_-

    RE: Routed Events in Silverlight


    posted by pwr on Nov 11, 2009 06:14
    Why does Results_MouseLeftButtonDown event stop reacting when Results element contains one or more items?
  • -_-

    RE: Routed Events in Silverlight


    posted by pwr on Nov 17, 2009 01:32
    This article's been translated for silverlight.su
  • -_-

    RE: Routed Events in Silverlight


    posted by prasad on Jun 27, 2010 06:44
    SL  supports three types of RoutedEvents - direct, tunneling, and bubbling
  • -_-

    RE: Routed Events in Silverlight


    posted by Anon on Sep 15, 2010 13:34
    The ClientUI from Intersoft provides routed events too and seem to be more advanced. Check it out here.
  • -_-

    RE: Routed Events in Silverlight


    posted by Kenrae on Nov 08, 2010 18:18

    DB:

    "why to propagate an event through visual tree, when it can be handled only by a specific type of controls?"

    Easy: because in some cases, we need a parent control to have a generic handler for children events. For example, it is VERY useful to have a Panel which handle the click event of all the buttons it contains.


    Specially since you don't have commands on Silverlight. I've just found it the hard way :(.

Add Comment

Login to comment:
  *      *