Okay, this has come up in the past but I haven't seen anything that I 
would call a good, solid general rule.

The question applies more generally, but I'm going to ask in the context 
of a Control.  How does one decide whether to write an "override" method 
to an event and when to simply add an event handler for that event?

For example, you can either write a new OnPaint override, or you can 
register a delegate that the Control's base OnPaint method will execute.

My current thought is that when you are not inheriting from the base 
class, you register a delegate (duh, since you obviously have no way to 
override the method in that case), and when you are inheriting from the 
base class, you override the method (the main reason here being that if 
you're inheriting from the base class, you want your new functionality to 
always work, rather than relying on your delegate remaining in the event 
handler list).

In other words, override when you can, add an event handler if you can't.

Is it really as simple as that?  Or are there other factors I should be 
considering?

Many thanks in advance for the wisdom of those who have gone down this 
road before me.  :)

Pete

it's as simple as that!
it's also easier to maintain...

when you override a method, all the functionality is in an easy to find
place.
if you use delegate, you've got hard to track bug, where you got to run the
debugger to realize some forgotten event handler have some annoying code...

Show quoteHide quote

I can see one other reason to override, and that is sequence. If you
override the "On..." method, you have the choice of executing your code
either before or after the base class's code. If you use a delegate, it will
always execute after the base class "On..." code. Sometimes you may want to
do the former.

Show quoteHide quote

Peter

for the sake of discussion

I have impression that main point is dynamic control. As you might know
event handlers could be changed on the fly, though maybe not always very
easy. Overrides are declarative, so you can change them only if you
regenerate assembly. So, objects with events behave more naturally and are
more flexible, generally speaking.

Also, on the more general side, "always" for new functionality is not that
good if you consider how quickly everything changes. New functions become
obsolete very quickly. Ideally, any component should be easily changed to
new version. Events are better suited for this versioning as they are by
nature dynamic. Overrides are too "hard-coded" for this.

Also I saw one point about "easier" to maintain. I do not agree overrides
are easier to maintain. No specific arguments yet in addition to above, but
somehow doesn't seem valid to me.

If event structure is designed properly, I would rather stay with events -
always. Main argument - to maximize re-use and maintainability I prefer not
to touch base functionality and not to deal with component (black boxes)
internals - of course, if only I don't develop component itself. If there is
a need to modify base class functionality, first what comes to my mind is
"design deficiency". Either for base class or for my class. One such example
is TreeView, which inconsistently raises Click event - from my point of
view, of course.
Show quoteHide quote

Amongst other things, there's a fairly significant performance advantage to
overriding vs handling events.  If you're authoring a subclass, overriding
should be your default approach.  The events are mainly there to be used by
consumers of the control, not its subclasses.


Show quoteHide quote

Locking Desktop and Threading Issue
Questions about clickOnce
The Interlocked on the Edge of Forever
Determining if two paths are the same
System.Speech