< Continued from page 4
Before WPF, an event was "owned" by the control raising it (Sender in the event subroutine argument list). Now that routed event can trigger event subroutine code from any element in the WPF visual tree, things have become a bit more confused. WPF gives you a way of nailing down exactly where some events are raised. It's called "attached events". In other WPF articles at About Visual Basic, I discuss "attached properties".
Attached events are similar.
One possible point of confusion is that not all events are declared as attached events. In fact, most are not. For example, you may see the Click event explained as an attached event in other articles. They use that example because it's the only one declared that way for ButtonBase (the actual object that raises the event) in the current version of WPF, VB.NET 2008/Framework 3.5. So the usefulness of attached event isn't as great as it might be ... yet.
Because you can find a lot on the web that documents how to use Click as an attached event, I decided to give you something different. Many systems use the F1 key to trigger Help. The simple example here uses the KeyUp event attached to a Grid container element to add text to a WPF TextBox when the F1 key is pressed. The application looks like this:
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
RadioButton, Displaying an Image
This app was written for a different purpose, but it can also illustrate an attachable event.
(If you want to read the "back story", read my blog about it here.) But if you're looking for a RadioButton example or an Image control example, this one might work for you as well. To download the project, Click Here.
The idea is that the name of a graphic can be entered into the
TextBox
and displayed in any of the four Image controls using the radio buttons. Click the OK button to display the graphic. If you forget the names of the graphics available, you can press F1 and get a display in the Label in the lower left corner.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
The XAML code looks like this:
      ... etc. ...
The KeyUp event from the Keyboard object can be attached to the Grid, which makes it possible to code a single event subroutine that handles all keyboard input. For this simple example, this event subroutine does it:
Private Sub Grid_KeyUp( _
   ByVal sender As System.Object, _
   ByVal e As System.Windows.Input.KeyEventArgs)
   If e.Key = Key.F1 Then _
      ImageHelp.Content = _
      "LilAngel" & vbNewLine & _
      "PumpkinHead" & vbNewLine & _
      "LilDevil" & vbNewLine & _
      "TouristHound"
End Sub
This works the same way even if the KeyUp event isn't qualified by the Keyboard object in this case. This happens due to the way the WPF Input API works.
In Part 6 of the series, we return to the simple application that we coded in Part 1 that changed the opacity of a label component. In that application, we borrowed a Timer component from the System.Windows.Forms namespace to smoothly change the Opacity property. In the next article, we do it the Microsoft recommended way and learn about a really new part of .NET that has become more important in WPF: multithreading. Go to Part 6.
Before WPF, an event was "owned" by the control raising it (Sender in the event subroutine argument list). Now that routed event can trigger event subroutine code from any element in the WPF visual tree, things have become a bit more confused. WPF gives you a way of nailing down exactly where some events are raised. It's called "attached events". In other WPF articles at About Visual Basic, I discuss "attached properties".
Attached events are similar.
One possible point of confusion is that not all events are declared as attached events. In fact, most are not. For example, you may see the Click event explained as an attached event in other articles. They use that example because it's the only one declared that way for ButtonBase (the actual object that raises the event) in the current version of WPF, VB.NET 2008/Framework 3.5. So the usefulness of attached event isn't as great as it might be ... yet.
Because you can find a lot on the web that documents how to use Click as an attached event, I decided to give you something different. Many systems use the F1 key to trigger Help. The simple example here uses the KeyUp event attached to a Grid container element to add text to a WPF TextBox when the F1 key is pressed. The application looks like this:
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
RadioButton, Displaying an Image
This app was written for a different purpose, but it can also illustrate an attachable event.
(If you want to read the "back story", read my blog about it here.) But if you're looking for a RadioButton example or an Image control example, this one might work for you as well. To download the project, Click Here.
The idea is that the name of a graphic can be entered into the
TextBox
and displayed in any of the four Image controls using the radio buttons. Click the OK button to display the graphic. If you forget the names of the graphics available, you can press F1 and get a display in the Label in the lower left corner.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
The XAML code looks like this:
      ... etc. ...
The KeyUp event from the Keyboard object can be attached to the Grid, which makes it possible to code a single event subroutine that handles all keyboard input. For this simple example, this event subroutine does it:
Private Sub Grid_KeyUp( _
   ByVal sender As System.Object, _
   ByVal e As System.Windows.Input.KeyEventArgs)
   If e.Key = Key.F1 Then _
      ImageHelp.Content = _
      "LilAngel" & vbNewLine & _
      "PumpkinHead" & vbNewLine & _
      "LilDevil" & vbNewLine & _
      "TouristHound"
End Sub
This works the same way even if the KeyUp event isn't qualified by the Keyboard object in this case. This happens due to the way the WPF Input API works.
In Part 6 of the series, we return to the simple application that we coded in Part 1 that changed the opacity of a label component. In that application, we borrowed a Timer component from the System.Windows.Forms namespace to smoothly change the Opacity property. In the next article, we do it the Microsoft recommended way and learn about a really new part of .NET that has become more important in WPF: multithreading. Go to Part 6.
SHARE
