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.
In general, each element in the XAML corresponds to an object in VB.NET. Each attribute corresponds to a property. This rule isn't absolute, but it's close and it's important that you understand the concept. For example, the XAML code ...
<Button
Name="Button1"
Height="50"
Margin="100,100,100,0"
VerticalAlignment="Top">
Button1
</Button>
... is essentially the same as the VB.NET code ...
Dim Button1 As New Button
Button1.Height = 50
Button1.Margin = New Thickness(100, 100, 100, 0)
Button1.VerticalAlignment = Windows.VerticalAlignment.Top
Button1.Content = "Button1"
myGrid.Children.Add(Button1)
When either the XAML code or the VB.NET code is compiled, it's turned into IL (Intermediate Language) code that are merged as Partial Classes to create the assembly for the solution. To demonstrate that they're essentially equal, the illustration below shows both Button objects together in the same running code:
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
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 Windows Forms based applications. 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"
Source="path to source file"/>
</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 (for example) a GotFocus event and it's possible to write unique event coding for the event in each of them. If you want to run this code yourself, remember to code the Source attribute too. For reasons that will be explained later, it's necessary, even though it might not seem like it now.
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
--------
On the next page, we check out what it means to bubble up and tunnel down through an element tree in WPF. And we see a concrete example of how it can confuse you.
