Hi Charles,
I think you are referring to the XXXX Event versus the OnXXXX method, eg the
Load Event versus the OnLoad method.
To understand this pattern, it's probably easiest to look at a simple case.
Let's assume you create a Class named A and a class named B, where B derives
from A (that is:
Class A
...
End Class
Class B : Inherits A
..
End Class
Now to A, add an Event Foo. Once you do this, in B you can actually subscribe
to the event, but you cannot raise the event or block the event from raising.
This is because only code in class A can raise the event. The reason for that is
the event is actually a private multicast delegate and hence cannot be invoked
from outside of the class, due to scoping rules. So to allow your derived class
B to raise the event Foo as declared in A, the usual practice is to declare an
Overridable method in A called OnFoo. The code in that method actually raises
the event Foo. So from A, anywhere you would want to raise the event, you call
the OnFoo method. This also allows B to override the OnFoo method, and take
some action before and or after the event is raised, or even to stop the event
being raised. And this is the important thing here, that code in B's OnFoo
method that overrides it's base class A' OnFoo method, needs to pass the call to
it's base class for the event to be fired. You do this via the MyBase keyword,
eg MyBase.OnFoo. If you did not do this, then say another class C derived from
B well it would not have the Foo event raised and could not raise it, as the B's
OnFoo would be effectively blocking that event from being raised.
As to which to use, in a derived class, that being overriding the base class's
method, or using the event, well the event possibly has a slightly higher
overhead, but probably not a significant factor (IMO). The override of the
OnXXX method does have greater functionality, but it also means that you must be
careful to ensure you call the base method.
HTH's
Bill.