Information Technology Reference
In-Depth Information
called. Determining whether there are event handlers and iterating each at
runtime takes more execution time than invoking one virtual function.
If that's not enough for you, examine the first listing in this item again.
Which is clearer? Overriding a virtual function has one function to exam-
ine and modify if you need to maintain the form. The event mechanism
has two points to maintain: the event handler function and the code that
wires up the event. Either of these could be the point of failure. One func-
tion is simpler.
Okay, I've been giving all these reasons to use the overrides and not use the
event handlers. The .NET Framework designers must have added events
for a reason, right? Of course they did. Like the rest of us, they're too busy
to write code nobody uses. The overrides are for derived classes. Every
other class must use the event mechanism. That also means declarative
actions defined in the XAML file will be accessed through the event han-
dlers. In this example, your designer may have actions that are supposed
to occur on a MouseDown event. The designer will create XAML declara-
tions for those behaviors. Those behaviors will be accessed using events
on the form. You could redefine all that behavior in your code, but that's
way too much work to handle one event. It only moves the problem from
the designer's hands to yours. You clearly want designers doing design
work instead of you. The obvious way to handle that is to create an event
and access the XAML declarations created by a design tool. So, in the end,
you have created a new class to send an event to the form class. It would
be simpler to just attach the form's event handler to the form in the first
place. After all, that's why the .NET Framework designers put those events
in the forms.
Another reason for the event mechanism is that events are wired up at
runtime. You have more flexibility using events. You can wire up different
event handlers, depending on the circumstances of the program. Suppose
that you write a drawing program. Depending on the state of the program,
a mouse down might start drawing a line, or it might select an object.
When the user switches modes, you can switch event handlers. Different
classes, with different event handlers, handle the event depending on the
state of the application.
Finally, with events, you can hook up multiple event handlers to the same
event. Imagine the same drawing program again. You might have multiple
event handlers hooked up on the MouseDown event. The first would per-
form the particular action. The second might update the status bar or
