Input with Windows Presentation Foundation - Routed Events and Normal Events
(Page 4 of 4 )
Normal .NET events (or, as they are often called, CLR events) offer one advantage over routed events: many .NET languages have built-in support for handling CLR events. Because of this, WPF provides wrappers for routed events, making them look just like normal CLR events.* This provides the best of both worlds: you can use your favorite language’s event handling syntax while taking advantage of the extra functionality offered by routed events.
This is possible thanks to the flexible design of the CLR event mechanism. Though a standard simple behavior is associated with CLR events, CLR designers had the foresight to realize that some applications would require more sophisticated behavior. Classes are therefore free to implement events however they like. WPF reaps the benefits of this design by defining CLR events that are implemented internally as routed events.
Examples 4-1 and 4-2 arranged for the event handlers to be connected by using attributes in the markup. But we could have used the normal C# event handling syntax to attach handlers in the constructor instead. For example, you could remove theMouseDownandPreviewMouseDownattributes from theEllipse in Example 4-1, and then modify the constructor from Example 4-2 , as shown here in Example 4-4 .
Example 4-4. Attaching event handlers in code
...
public Window1() {
InitializeComponent();
myEllipse.MouseDown += MouseDownEllipse;
myEllipse.PreviewMouseDown += PreviewMouseDownEllipse;
}
...
When you use these CLR event wrappers, WPF uses the routed event system on your behalf. The code in Example 4-5 is equivalent to that in Example 4-4.
Example 4-5. Attaching event handlers the long-winded way
...
public Window1() {
InitializeComponent();
myEllipse.AddHandler(Ellipse.MouseDownEvent,
new MouseButtonEventHandler(MouseDownEllipse));
myEllipse.AddHandler(Ellipse.PreviewMouseDownEvent,
new MouseButtonEventHandler(PreviewMouseDownEllipse));
}
...
Example 4-5 is more verbose and offers no benefit—we show it here only so that you can see what’s going on under the covers. The style shown in Example 4-4 is preferred.
The code behind is usually the best place to attach event handlers. If your user interface has unusual and creative visuals, there’s a good chance that the XAML file will effectively be owned by a graphic designer. A designer shouldn’t have to know what events a developer needs to handle, or what the handler functions are called. Ideally, the designer will give elements names in the XAML and the developer will attach handlers in the code behind.
Please check back in two weeks for the next part of this series.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
 This article is excerpted from Programming WPF, Second Edition, written by Chris Sells and Ian Griffiths (O'Reilly, 2007; ISBN: 0596510373). Check it out today at your favorite bookstore. Buy this book now.
|
|
/ 3 
