If you haven't looked at part 1 of this series, you might want to go back and check it out first. Also, all code here is based on VB.NET 2008 Express, to be certain that you can use totally free software.
Up to this point in the WPF and XAML series, we haven't actually written any VB code because XAML is such a fundamental change. We needed to establish a foundation in that technology first. In this part of the series, that will change!
The term "event model" means the preplanned way that your code works with Framework code. For example, you know that you can code a subroutine that "handles" a click event. In WPF, there are big changes in the "event model" too.
To begin, there are two places that you can code events now. There is one .vb file for application level events in Application.xaml.vb such as Startup and Exit and another for component events like handling button clicks in windowname.xaml.vb (where windowname is determined in your project).
Although some of the components may seem familiar, they're loaded with new methods and properties. For example, the WPF Button component has a three-way ClickMode property: Press, Release, and Hover.
One new function that WPF components offer is a completely new routed events model.
Suppose we want to code a VB.NET event that will respond to a GotFocus event for an image. To make this more clear, let's look at the corresponding code for a Windows Forms application and an Image control.
There is now no direct equivalent to an Image component in VB.NET. The nearest thing to an WPF Image in Windows Forms is a PictureBox control. A GotFocus event for this control in Windows Forms looks like this:
Private Sub PictureBox1_GotFocus( _
ByVal sender As Object, _
ByVal e As System.EventArgs) _
Handles PictureBox1.GotFocus
. . .
End Sub
In WPF, a similar event looks like this:
Private Sub Image1_GotFocus( _
ByVal sender As Object, _
ByVal e As System.Windows.RoutedEventArgs) _
Handles Image1.GotFocus
. . .
End Sub
Notice the difference in the object used for the e argument. WPF uses RoutedEventArgs. The key to understanding events in WPF is understanding why this change is necessary.
Remember that WPF builds everything as a tree-structured hierarchy. For example, consider the following XAML code that might be used to display the Image control:
<Border Name="Border1">
<DockPanel Name="DockPanel1">
<StackPanel Name="StackPanel1">
<Image Name="Image1"/>
</StackPanel>
</DockPanel>
</Border>
This is often called the "visual tree" in WPF.
Every one of the components that this XAML code describes will respond to a GotFocus event and it's possible to write unique event coding for the event in each of them.
RoutedEventArgs is derived from EventArgs (so it has the same properties) plus some additional ones designed to solve this problem. The illustration below shows the new properties.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
The new properties for RoutedEventArgs are:
- Handled - Since multiple objects can handle the event, this property tells your code whether it has already been handled by some earlier event code. You should set this property in your own event handlers.
- OriginalSource - This is the object that first raised the event. This doesn't change as different event code is processed.
- RoutedEvent - The type of event that was raised is in this property. Because different events can have the same signature (argument list) and event code can handle multiple events, you may need this to keep things straight.
- Source - The object that raised the event. In WPF, this isn't the same as the Sender.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
In WPF, an event is usually (but not always) processed by the innermost element code (Image in the example above) and then "bubbles" up through the element tree until it reaches the root. In WPF, that will usually be a Page or a Window. In addition to bubbling up, events can also tunnel down: From the root down to the innermost element.
To see more than one component in the visual tree handling the same event, add this code to the code-behind file:
Class Window1
Private Sub Image1_MouseLeftButtonDown( _
ByVal sender As Object, _
ByVal e As System.Windows.Input.MouseButtonEventArgs) _
Handles Image1.MouseLeftButtonDown
Console.WriteLine( _
"Image - MouseLeftButtonDown")
' e.Handled = True
End Sub
Private Sub StackPanel1_MouseLeftButtonDown( _
ByVal sender As Object, _
ByVal e As System.Windows.Input.MouseButtonEventArgs) _
Handles StackPanel1.MouseLeftButtonDown
Console.WriteLine( _
"StackPanel - MouseLeftButtonDown")
Console.WriteLine("Source: " & e.Source.ToString)
End Sub
End Class
You'll see both events in the Output window for every mouse click and the source of the event will be the Image1 object. Now uncomment the e.Handled = True statement and run it again. This time, only one event subroutine will responds.
Tunneling events can be found with the prefix "Preview" in front of their event names:
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
These are called before the bubble up events. You can add e.Handled = True to the event code for a preview event near the top of the visual tree to prevent all of the subsequent events from being called. This code will do the trick for our code:
Private Sub Border1_PreviewMouseLeftButtonDown( _
ByVal sender As Object, _
ByVal e As System.Windows.Input.MouseButtonEventArgs) _
Handles Border1.PreviewMouseLeftButtonDown
e.Handled = True
End Sub
The final article uses the maximum number of pages allowed to get everything in. Here's Part 6: TripPlanner - A Complete WPF and XAML in Visual Basic.
