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

[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

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:O4******** ******@TK2MSFTN GP11.phx.gbl...

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
"Richard Blewett [DevelopMentor]" <ri******@NOSPA Mdevelop.com> wrote in
message news:uE******** ******@TK2MSFTN GP10.phx.gbl...

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.

[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

"Richard Blewett [DevelopMentor]" <ri******@NOSPA Mdevelop.com> wrote in
message news:O4******** ******@tk2msftn gp13.phx.gbl...

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.

[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.

On Tue, 04 Jan 2005 10:00:51 -0800, "Richard Blewett [DevelopMentor]"
<ri******@NOSPA Mdevelop.com> wrote:

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(PaintEv entArgs e)
{
// Do your custom painting here

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

--
http://www.kynosarges.de

[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.

--
John Wood
Blog: http://spaces.msn.com/members/johnwood/
"Sam Kong" <su***********@ hotmail.com> wrote in message
news:e9******** ******@TK2MSFTN GP09.phx.gbl...

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

[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
"John Wood" <sp**@isannoyin g.com> wrote in message
news:eB******** ******@TK2MSFTN GP11.phx.gbl...

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.
--
John Wood
Blog: http://spaces.msn.com/members/johnwood/
"Sam Kong" <su***********@ hotmail.com> wrote in message
news:e9******** ******@TK2MSFTN GP09.phx.gbl...

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

[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]

Christoph Nahr wrote:

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.

On Tue, 04 Jan 2005 10:00:51 -0800, "Richard Blewett [DevelopMentor]"
<ri******@NOSPA Mdevelop.com> wrote:

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(PaintEv entArgs e)
{
// Do your custom painting here

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

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