One group favors the OnLoad event since it can have code that runs
either before or after the parent's processing for that event, i.e.,
put in the "MyBase.OnLoad(e)" statement either before or after your
custom code. The down-side is that you MUST remember to manually
include that statement somewhere or the form's standard "Load" event
won't fire at all.
Another group considers the "Load" event better since it parallels the
form events available in VB6 and you don't have to remember to put in
the "MyBase.OnLoad(e): statement, but I believe it will always run
after the parent's Load event.
One obvious response would be to say to use whichever meets the current
app needs, but we want to standardize on one method to make working on
each others' code easier.
There seems to be more event choices in the "(Overrides)" list but I
haven't done a direct comparison yet.
We are leaning toward standarding on using the "(Overrides)" events in
all cases due to the extra flexibility, but we are wondering if there
are factors that we are not yet aware of. Are there any down-sides to
this that we are missing? If we have a child inherit from a form that
uses an OnLoad, will that cause any problems? Will the child still be
able to override it with it's "OnLoad" event?
I appreciate any comments and further clarification of how this works
and any impacts. Thanks !!!
Joe Kunk
That would be my instinctive to place to put such code (or call a
method that does what you need to setup) in the constructor for ease of
inheritance.
Hope this touched on enough to be of use.