Re: Application.Run() problem

"Joel" <joelagnel@xxxxxxxxx> wrote in message
news:1160999165.328201.103510@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thank you for your response and I apologise for posting the
follow-up.

Apology accepted. :)

I feel much better about the first question I asked but I
still am very much confused about the paint event handler.

Me too...but I think in a different way than you are. :)

[...]
I want to know, which event holds the delegate list, is it the base
class or the derived class?
It most obviously should be the derived class, but in the Control-Form
case, it seems to be the base class (Control) whose paint event holds the
list of the registered paint event handlers of the derived class.

It seems that you're not understanding how inheritance works. When a class
derived from Control inherits an event from that class, there is no "derived
event". The inheriting class simply gets to use the base class's event as
if it were its own.

In only specific situations will an inherited member of a class be different
from the base class's member. In each of those situations, some additional
work must be done to explicitly cause the inherited member to actually
supercede the base member. At the minimum, a new instance of that member
must be defined in the derived class. And typically, this is done only for
override (virtual) methods, which ensures that the base class uses the same
new instance of the member that the derived class is using.

This extra work doesn't exist for the events you're asking about. The
derived classes don't define new events that supercede the base class's
instances. So when a derived class inherits those events, they are the
exact same events known to the base class. It works in exactly the same way
that a method in the base class is inherited in the derived class without a
new instance of the method being created. When the derived class calls the
inherited method, the code that's run is the code that was originally
defined for the base class, not some new code that was created as a
consequence of the inheritance. Likewise, the inherited event is not some
new event that was created through inheritance, but rather just the original
event the base class had.

So, if you are using the paint event to register a paint handler, you use
the same paint event defined in the base Control class, even though you may
be dealing with an inherited class. There's no additional event in the
derived class unless one has been explicitly defined, and one hasn't been
explicitly defined because it's not needed.

Pete


.

Relevant Pages

  • Re: attribute or subclass
    ... With inheritance the derived class code ... reference in place of the base class reference. ...
    (comp.object)
  • Re: LoadString overwrite
    ... base class doesn't have a virtual destructor. ... derived class, thinking they are "overriding" them, because they are not. ... Clearly if a class doesn't have a virtual destructor, ... However there are lots of things you can do using inheritance quite apart ...
    (microsoft.public.vc.mfc)
  • Re: Application.Run() problem
    ... When a paint event occurs in the form, ... when we register event handlers using multi cast delegates ... It most obviously should be the derived class, ... It seems that you're not understanding how inheritance works. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Very Confused on Page 33
    ... On page 33 Bruce is explaining inheritance. ... > base class you can also send to objects of the derived class. ... The programmatic difference enables the subclass ...
    (comp.lang.java.help)
  • Re: Simple Inheritance question
    ... base.SomeMethodyou are indeed calling the base class implementation. ... you are using inheritance purely for "implementation inheritance" then the ... implementations based on the derived class. ... > I overrided the base method implimentation? ...
    (microsoft.public.dotnet.languages.csharp)