event vs method override

[bhavin]

Hi,
Can someone point me to some good best practices kind of documentation on
use of events compared to method overriding.
Ex. In Windows Forms when should i have an event handler for Paint, and when
should i override OnPaint?

I have to implement added functionality in a child class, and am in two
minds .. to have the parent fire an event, or make the method virtual and
override in the child. Am hoping some reading with description of various
scenerios will increase my understanding and eventually help me make the
decision.

thanx in advance
-bh

 

[John Wood]

I can't think of a document, sorry.
But I can give you my opinion.

Choosing to use an override forces your user to inherit from the class, so
only choose override as an option when you'd be expecting the user to
customize the behavior of your class (which itself isn't generally a very
common thing) by modifying what would normally be implementation details of
your class.

Choose events when you want to notify of something so they can potentially
go off and do something else, consider situations where more than one object
may subscribe to the event, something which isn't possible with overrides.

 

[Richard Blewett [DevelopMentor]]

There are two crucial differences between overriding and adding an event handler

1) To override you need to be a derived class (obviously) whereas anyone can add an event handler to a control.

2) The base class version of these virtual methods fires the event handlers. So if you need to layer in code in a specific place relative to when the event handlers fire (before or after) overriding is the only sure-fire way of doing this. The Paint event is a great example of this. Normally, people add a paint event handler to "decorate" your control from its standard appearance. You need to make sure the control paints it's appearance before the event handlers run otherwise you will draw over the top of the decorations. So the folllowing is the standard pattern for a custom control

protected override void OnPaint(PaintEventArgs e)
{
// Do your custom painting here

base.OnPaint(e); // this fires thte event handlers
}

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi,
Can someone point me to some good best practices kind of documentation on
use of events compared to method overriding.
Ex. In Windows Forms when should i have an event handler for Paint, and when
should i override OnPaint?

I have to implement added functionality in a child class, and am in two
minds .. to have the parent fire an event, or make the method virtual and
override in the child. Am hoping some reading with description of various
scenerios will increase my understanding and eventually help me make the
decision.

thanx in advance
-bh

 

[carl.manaster]

http://www.bobpowell.net/overrideorhandle.htm

Peace,
--Carl

 

[bhavin]

My client class IS a child of the main class. We are building a forms
framework, which acts as a core for the individual forms (which also will be
created by us). So the form class in the final form assembly is inherited
from the framework form class.

I was hoping to get various usecases which will help me decide, depending on
which usecase i can relate to.
Though it is a child class i am leaning towards using events for this
specific case.

-bh

 

[carl.manaster]

http://www.bobpowell.net/overrideorhandle.htm

Peace,
--Carl

 

[bhavin]

Thanks Carl for the link.
Its an interesting article and Bob end it with
" Generally, if you are deriving from a control, always override. A control
should never handle it's own events because to do so can seriously effect
the rules of object-orientation. "
Would experts here maintain the same opinion about controls, and other
non-control inherited classes?
It kinda makes me think about my idea of using events in a child class to
extend more functionality.

-bh

 

[Jay B. Harlow [MVP - Outlook]]

bh,
I tend to view events as external to the class, they are used to notify
other objects that something interesting happened to this object.

While Overridable methods are internal to the class, they are used to notify
base or derived classes (the object itself) that something interesting
happened to the object (itself).

I don't have the specific reference on MSDN however I distinctly remember
reading that calling an overridable method will be faster then raising an
event.

The following mention using the override instead of the event:

http://msdn.microsoft.com/library/d...s/cpgenref/html/cpconEventUsageGuidelines.asp

http://msdn.microsoft.com/library/d.../cpgenref/html/cpconEventNamingGuidelines.asp

The first link mentions "The purpose of the method is to provide a way for a
derived class to handle the event using an override. This is more natural
than using delegates in situations where the developer is creating a derived
class".

It may have been in this article, however I am not seeing it right now:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenet.asp

Hope this helps
Jay

 

[Richard Blewett [DevelopMentor]]

In terms of Windows Forms controls the speed argument is a total red herring - how about a click event

1) there is a user involved - and so they are thinking
2) they decide to click the mouse - to actually do this will take a reasonable amount of time (milliseconds?)
3) there is a hardware interrupt as the mouse click is received
4) the mouse click has to make it from Kernel mode to User mode and be *posted* to the relevent windows message queue
5) the message pump picks up the message and dispatches it to the windows procedure

The small number of machine instructions difference between virtual and delegate based dispatch is lost in the noise. The crucial thing is the ability to layer in code relative to event firing.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

I don't have the specific reference on MSDN however I distinctly remember
reading that calling an overridable method will be faster then raising an
event.

 

[Jay B. Harlow [MVP - Outlook]]

Richard,

The crucial thing is the ability to layer in code relative to event
firing.

I'm not specifically sure what you mean here.


I agree the "speed" argument is largely a red herring, especially in the UI.
(the 80/20 rule).

However! My main point was not about speed, the main point I was attempting
to make was about internal verses external notification!

Although I did not mention I also agree with the design guidelines, using
the override for derived classes is "more natural", being "more natural" is
also more important then performance (again the 80/20 rule)...

Jay

 

[bhavin]

Thanks Jay for the tips and the links too.
Speed is not of much concern for me right now as much as common/best
practice is, so I think I will go the override way.
Just wanted to be sure i do it the more common way and not just develop some
code which works.. somehow. Also if i have a reason to something one way out
of 2 possible, i will be more consistent. Else i'll use one and then the
other in another case just because.

Thanks a ton again.
-bhavin

 

[Richard Blewett [DevelopMentor]]

I mean that by overriding you can layer code in before or after the event handers run with confidence that you are in control of the ordering

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Richard,

The crucial thing is the ability to layer in code relative to event
firing.

I'm not specifically sure what you mean here.

 

[Jay B. Harlow [MVP - Outlook]]

Richard,
Yes I thought that was what meant after I read my posted response to you.

For some reason it did not occur to me when I was composing my response...

Thanks
Jay

 

[Sam Kong]

Its an interesting article and Bob end it with

" Generally, if you are deriving from a control, always override. A
control
should never handle it's own events because to do so can seriously effect
the rules of object-orientation. "
Would experts here maintain the same opinion about controls, and other
non-control inherited classes?

I generally agree with the statement.
However, I am not sure about Forms.
What would you do with a Form?
When you write a code for a form, actually you define a class (like class
Form1).
Would you use Paint handler or override OnPaint method?


Sam

 

[Christoph Nahr]

That should be the other way round, I think: first call base.OnPaint,
then add your custom paint code. Otherwise, whatever you painted
might get overwritten by the base call.

 

[John Wood]

I'm not quite sure why they decided to make paint an event... but probably
so that other components can hook into the paint of the form and 'paint on
top'. It at least makes it possible to have more than one painter of a form.

 

[gerry]

My guess would be so that it could be accessed via designers - drop a
control on a form and add code to its Paint event rather than having to :
- derive a control
- override the OnPaint method
- add the new control to your form programatically
OR
- create a new control library containing your new control so that the
new control could be dropped on a form

 

[Richard Blewett [DevelopMentor]]

I'm sure I posted this earlier in the thread, but the main reason for having a paint event is to allow consumers of your control to "decorate" its appearance with their own custom drawing

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

My guess would be so that it could be accessed via designers - drop a
control on a form and add code to its Paint event rather than having to :
- derive a control
- override the OnPaint method
- add the new control to your form programatically
OR
- create a new control library containing your new control so that the
new control could be dropped on a form

 

[Benoit Vreuninckx]

That should be the other way round, I think: first call base.OnPaint,
then add your custom paint code. Otherwise, whatever you painted
might get overwritten by the base call.

I partially agree.
In this case (OnPaint), the base implementation should be called first
as it does some sort of default painting, which obviously should be done
first. But after the default painting, the hooked-up event handlers are
invoked to draw the previously-so-called decorations, eventually
followed by the overriding implementation(s) for yet another batch of
customized drawing which may *overpaint* our precious decorations.
So actually, no solution is better.
The order of execution is key in this situation. But in most other
cases, the order of invocation is not that important, as long as the
handlers (and overriding implementations) *eventually* do get invoked.

Cheers,

Benoit