Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

OnEventName Procedures

I need some illumination on the designing OnEventName procedures.  Are these procedures only supposed to raise an event, or is it acceptable to put additional code in there as well?

I ask because I'm seeing unexpected (to me) behavior in a UI control derived from System.Windows.Forms.Panel.  The derived control overrides OnBackColorChanged.  If the BackColor property is set, the property value changes.  However, the control only redraws when derived control calls MyBase.OnBackColorChanged.


Joe Paradise
Thursday, February 10, 2005

It's certainly true that the standard pattern for the base implementation of a protected method OnEventName is to simply raise the event EventName.

Panel inherits its OnBackColorChanged method from Control, which as can be confirmed using Reflector does indeed to additional work as well as raising the event.

Which just shows that Microsoft don't always follow the patterns they recommend.

Thursday, February 10, 2005

Thanks for the reply Joe.  Didn't even think to use Reflector to look at Panel & Control.  As for MS not following their own standards, well, that's about what I expected.  At least I (now) know what the standard is so my code isn't as sloppy.

Joe Paradise
Thursday, February 10, 2005

I disagree,  What's the control supposed to do if it needs to take action when that type of event is occuring, hook into its own events?

If you are deriving from a class that raises events in that way then overriding the protected OnXXX function lets you optionally do something before the event is fired to users of the object, optionally invoke the base class functionality (possibly with modified event arguments) and then optionally do something afterwards.  Seems a perfectly fine design pattern to me.  Plenty of scope for hooking into the event handling process in different ways as required.

Thursday, February 24, 2005

*  Recent Topics

*  Fog Creek Home