Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
The .NET Framework has supported the event since the very beginning. Before we look at Silverlight events let's review .NET events. An event is a message that is sent via the .NET Framework from one type to another. It might be from the Button to the Form that contains the Button; it might be from a TextBox to Window. In .NET when you create an event you add it to a type definition. It is defined within the type, an event is considered a type member just like methods, fields, and properties. The event is raised within the type, for instance if I have a text box it raises the text changed event whenever the text changes in the text content.
Other classes might be interested in subscribing to that event. To subscribe, a developer creates a function in the subscriber code with the correct signature. Then the developer registers their subscription with the .NET Framework. When the event is raised the .NET Framework dispatches the event to each subscriber. WPF is the precursor to Silverlight, the WPF team's mission was to create a new UI rendering system for Windows. As part of that initiative they decided to enhance the existing event system.
They were not the first group to contemplate this challenge. Other UI systems have an interesting version of events known as Event Bubbling, which is a terrific solution to the UI composition problem. Let me give you an example of the problem. Silverlight controls like the button can contain sub elements and other child contents. For instance I might have a Button that contains a Border, within that border is a Grid and within that is an Image. The problem for the UI developer is that it is messy and tedious, and error-prone to create event procedures for the composite UI.
In the .NET world you have to add a procedure for each child element of the parent control. So if I have an image inside of the button I would have to write a MouseDown event inside the image and it also have to write at the Button level. With the routed events however events can bubble up to the handler in the parent element. Here is an example of the composition problem. The XAML on this slide will render a button that looks like the screenshot. As you can see from the screenshot I have a text block and an image there inside the StackPanel.
That StackPanel is inside the blue border and that blue border is inside the button. The button has a different aspect ratio than the border so the user could potentially click on the button or on the blue border or on the image or on this text block. Prior to the routed events I would have to write one procedure in each of those areas to listen for the MouseDown or the MouseUp event, let's say. Routed events are a simple and elegant solution to this dilemma. A Routed Event traverses the tree of UI elements, and it calls every registered handler on the way up the tree.
It starts at what it's called the originating leaf and moves up to the root node. It always moves in an upward direction. This event bubbling is the solution to the composition problem. You could add your mouse up handler at the Button level and no handlers for the children. Now when the user clicks on each child element the button handler is invoked. You'll see how this is implemented in the next movie.
Get unlimited access to all courses for just $25/month.Become a member