preferred way to handle form events

  • Thread starter Thread starter John A Grandy
  • Start date Start date
J

John A Grandy

I'm new to WinForms.

What's the preferred way of implementing event handlers for a Form ?

Override the protected "OnEvent" methods ... ?

Write a custom handler and add to the event a new delegate initialized to
the handler ?

Thanks.
 
John said:
I'm new to WinForms.

What's the preferred way of implementing event handlers for a Form ?

Override the protected "OnEvent" methods ... ?

Write a custom handler and add to the event a new delegate initialized to
the handler ?

Thanks.
Click to expand...

The second option, I believe. The "OnEvent" methods' work is, AFAIK, to
fire the "Event" event. I guess you could override these ones if you
need to do more stuff like, say, firing specific events.
 
I believe that's true , the "OnEvent" methods fire the events.

So, placing code in them is putting the cart before the horse, so to speak.
It might work, but it's not really correct. Code responding to an event
should be in handlers that are attached to the event and run after the event
is fired.
 
John said:
I believe that's true , the "OnEvent" methods fire the events.

So, placing code in them is putting the cart before the horse, so to speak.
It might work, but it's not really correct. Code responding to an event
should be in handlers that are attached to the event and run after the event
is fired.
Click to expand...

Exactly. Thus I'd rather subscribe to the events.

:)
 
There are mixed views on this subject.

Looking at it from a pure architecture viewpoint I would say that if there
is any intention that the final object will be derived from later then the
OnXXX overrides should be used in preference to the events. If the object,
such as a form, is known to be the final version then the events may be
used.

It is interesting to note that C# and VB design times handle these cases
differently. C# subscribes to the event and VB adds an override which is
more architecturally sound when you consider the implications for
polymorphism that handling ones own events implies.

The C# practice of adding an event handler is very bad because there is
technically no way to remove these handlers should the derived class need
to. I therefore write such handler code by hand in the case of user controls
because I write almost exclusively in C# and I require that polymorphism
rules are obeyed in case I need to derive from the user control at a later
date.

I cite this because really a user control, at least in it's design-time
mode, can be considered like a form without a title bar.



--
--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
 
You can remove an event handler in C# with a line looking almost identical to
the line that adds it (found in the designer file) but change the += to -=
 
Back
Top