Form_Load vs Constructor

[Smithers]

I have some logic that populates UI controls with values from App.config. A
couple of checkboxes get checked or unchecked; and items loaded into a
checked list box.

Two reasonable places to put this code:
1. the form's constructor (or in a method called from within the
constructor)
2. the Form_Load event procedure

What are the important considerations or tradeoffs entailed by those two
choices?

Thanks.

 

[Nicholas Paldino [.NET/C# MVP]]

Smithers,

If you place the code in the form's constructor, then you have to make
sure that you know that all the objects representing the child controls (the
instances of the objects, not the window handles) have been created (after
the InitializeComponent method, generally, if you are using
designer-generated code).

The Load event is called before the form is shown for the first time,
but after the form is constructed, so you know the child controls have been
created at this point.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Preference basically, if you put it in the constructor just make sure of
doing it after the call to InitializeComponents()

 

[Michael C]

I have some logic that populates UI controls with values from App.config. A
couple of checkboxes get checked or unchecked; and items loaded into a
checked list box.

Two reasonable places to put this code:
1. the form's constructor (or in a method called from within the
constructor)
2. the Form_Load event procedure

What are the important considerations or tradeoffs entailed by those two
choices?

Use the OnLoad override instead, events are there so *other* objects can get
notifications, an object should not generally use it's own events to get
notifications.

You can probably use the constructor as other's have said but this is what
the Load event is for so IMO it is more technically correct to put it there.

Michael

 

[Smithers]

RE:
<< events are there so *other* objects can get notifications, an object
should not generally use it's own events to get
notifications>>

Can you please clarify? I'm not sure what you mean by "can get
notifications" - - is there something about calling from the constructor
that would prevent it?

Thanks.

 

[Michael C]

RE:
<< events are there so *other* objects can get notifications, an object
should not generally use it's own events to get
notifications>>

Can you please clarify? I'm not sure what you mean by "can get
notifications"

An event is designed so other objects can get notifications from an object.
Eg, when someone clicks a button the click event is raised and the form is
"notified" of the click. A form itself does not need to use an event to get
it's own notifications, it can use the override instead.

- - is there something about calling from the constructor that would
prevent it?

This is not in reference to the constructor, I'm comparing using events to
overrides.

Michael

 

[Smithers]

I understand your points, I'm just not connecting them with the OP. In the
OP I'm wondering where to put some initialization code, and don't see how
the facts you state (which I agree with) relate to the question of where to
put initialization code.

RE:
<< A form itself does not need to use an event to get it's own
notifications, it can use the override instead>>
Yes, of course, but what does this have to do with the OP?

RE:

This is not in reference to the constructor, I'm comparing using events to
overrides.

I see that... just not making the connection of that point with your
apparent recommendation for using Form_Load.

I suspect you know what you are trying to say... not sure it's coming across
though.

-"Smithers"

 

[Jack Jackson]

The OP asked about the constructor vs the Load Event.

Michael was just pointing out that if you decide to put code in the
Load Event it is better to override the form's OnLoad method rather
than hooking into the actual Load Event.

 

[Peter Duniho]

I understand your points, I'm just not connecting them with the OP. In the
OP I'm wondering where to put some initialization code, and don't see how
the facts you state (which I agree with) relate to the question of where to
put initialization code.

In your original post, the two options you offered were to use the
constructor, or to use a handler for the Load event.

If I may, I believe that his point is that the second option should not
have been among the offered options. Instead, overriding the OnLoad()
method would be more appropriate, assuming you want the work to be done
during the Load event in the first place.

If the code winds up in the constructor, obviously that's a moot point.
But if it is appropriate to put it in the Load event handling, he's
saying you should do that by writing an override for OnLoad, rather than
handling the event itself.

Personally, while I agree with his point, I can't say I feel it matters
much one way or the other. If I have a situation in which I can
override the event-related method directly rather than subscribing to
the event, and there's no other design requirement necessitating the use
of the event, I will write an override rather than subscribing to the
event. But opinions may vary (and I know for a fact that they do ),
and I can't really say that subscribing to the event is necessarily a
bad design, even when an override is possible.

Pete

 

[Michael C]

I suspect you know what you are trying to say... not sure it's coming
across though.

I'm suggesting a third option, not putting it in the constructor or the load
event but in the OnLoad override instead. With regards to using the
constructor vs OnLoad I think it is better NOT to put it in the constructor
as it is slightly technically more correct to put it in OnLoad. While it
works in the constructor it is more self documenting IMO to have it in
OnLoad simply because that is what the event is for. Whatever you do
consistancy is of course important.

Michael

 

[Michael C]

Personally, while I agree with his point, I can't say I feel it matters
much one way or the other. If I have a situation in which I can override
the event-related method directly rather than subscribing to the event,
and there's no other design requirement necessitating the use of the
event, I will write an override rather than subscribing to the event. But
opinions may vary (and I know for a fact that they do ), and I can't
really say that subscribing to the event is necessarily a bad design, even
when an override is possible.

I can see a couple of reasons to use the override. First, it is more
efficient than using an event. Second, the override is potentially more
reliable as it's possible to not have the event being listened to and it is
not immediately obvious (I have had this happen). I know these are fairly
minor points but if one method is slightly better yet equivelant isn't it
better to go with the one that is slightly better?

Michael

 

[Smithers]

Thank you [and others] so much for clarifying. It totally makes sense now.

-"Smithers"

 

[Peter Duniho]

I can see a couple of reasons to use the override. First, it is more
efficient than using an event.

While I agree that it's probably marginally more efficient, the override
is still virtual, so still is an indirect function call, just like the
event. I doubt there's a significantly measurable difference.

Second, the override is potentially more
reliable as it's possible to not have the event being listened to and it is
not immediately obvious (I have had this happen).

Assuming your own override correctly calls the base implementation, it's
only possible for an event to not be raised if the class has been
overridden and someone else's override of OnLoad doesn't call the base
implementation. Which, as it turns out, is the same scenario in which
your own override won't get called either.

In other words, the event and the override both have the potential for
not being called, and it's unclear to me that one is more likely than
the other, since the scenarios are the same.

I know these are fairly
minor points but if one method is slightly better yet equivelant isn't it
better to go with the one that is slightly better?

Like I said, I personally prefer using the override. It does seem more
correct to me. But I wouldn't want to waste time arguing about it with
someone who was set on using the event instead. I'm not convinced
there's a big enough difference to make it worth worrying about.

IMHO, one significant thing that the override gets you is the ability to
effectively cancel the event, even if it's not a cancellable event. But
this need is unusual, and doesn't apply in the more general case (even
though it does obviously apply in that specific scenario). In the
general case, I really don't see a significant difference between the
two except stylistically.

Pete

 

[Michael C]

While I agree that it's probably marginally more efficient, the override
is still virtual, so still is an indirect function call, just like the
event. I doubt there's a significantly measurable difference.

That does make sense, even if it was significantly more efficent it's
unlikely to be called repetitively enough to be an issue.

Assuming your own override correctly calls the base implementation, it's
only possible for an event to not be raised if the class has been
overridden and someone else's override of OnLoad doesn't call the base
implementation. Which, as it turns out, is the same scenario in which
your own override won't get called either.

This is true although less likely. Usually if an override is used the event
won't be.

In other words, the event and the override both have the potential for not
being called, and it's unclear to me that one is more likely than the
other, since the scenarios are the same.

While they are possibly both equally likely it is more likely the event will
be a problem. The event is a problem in 100% of cases where the override
might be a small percentage.

Like I said, I personally prefer using the override. It does seem more
correct to me. But I wouldn't want to waste time arguing about it with
someone who was set on using the event instead. I'm not convinced there's
a big enough difference to make it worth worrying about.

There is a reasonable overhead involved with events.

IMHO, one significant thing that the override gets you is the ability to
effectively cancel the event, even if it's not a cancellable event. But
this need is unusual, and doesn't apply in the more general case (even
though it does obviously apply in that specific scenario). In the general
case, I really don't see a significant difference between the two except
stylistically.

You also get the ability to have your code executed first, or last, or both.
Not that I consider that to be a huge issue either because you could just
change it if it became an issue.

Michael

 

[Peter Duniho]

[...]

Assuming your own override correctly calls the base implementation, it's
only possible for an event to not be raised if the class has been
overridden and someone else's override of OnLoad doesn't call the base
implementation. Which, as it turns out, is the same scenario in which
your own override won't get called either.

This is true although less likely. Usually if an override is used the event
won't be.

That's not true, especially if you follow the stipulation that the event
is for use only by code outside the class. If one assumes that the
event is useful at all (and if it's not, why does it exist?), then by
your stipulation, there _is_ still going to be code that uses it, even
if the OnLoad() method is overridden.

The two are not mutually exclusive, and that is _especially_ true under
the conditions you and I both agree are more desirable (that is, the
event is used only by code outside of the class).

While they are possibly both equally likely it is more likely the event will
be a problem. The event is a problem in 100% of cases where the override
might be a small percentage.

I don't understand that statement. The only typical scenario I can
think of where a properly subscribed event wouldn't get raised is when
the OnLoad() method was overridden, but improperly so that the base
implementation wasn't called, and thus the event wasn't raised.

An improper override is the cause in both the problematic override case
and the problematic event case. Since both have the same cause, both
consequences should have the same relative occurrence.

So, I don't understand what you mean by "the event is a problem in 100%
of cases where the override might be a small percentage". 100% of which
cases? A small percentage of which cases? Why are the two rates of
incidence not the same, given that the underlying cause _is_ the same?
Shouldn't the rate of incidence be equal to the rate of incidence for
the underlying cause? And then wouldn't the rate of incidence for both
types of problems be equal, given that they are both equal to the same
number?

There is a reasonable overhead involved with events.

For example? What overhead specifically are you talking about? In what
way is using an event significantly more expensive that using an override?

Pete

 

[Michael C]

That's not true, especially if you follow the stipulation that the event
is for use only by code outside the class. If one assumes that the event
is useful at all (and if it's not, why does it exist?), then by your
stipulation, there _is_ still going to be code that uses it, even if the
OnLoad() method is overridden.

I think it is true. If you override OnLoad then it is unlikely that you will
also use Form_Load. Certainly it is less likely.

I don't understand that statement. The only typical scenario I can think
of where a properly subscribed event

You're assuming a properly subscribed event. I'm comparing someone
forgetting to call OnLoad to someone who has failed to subscribe to the
event correctly. In the case of failing to call OnLoad it is possible (and
likely) that code will continue to work because the event might not be used.
In the case of the event not being subscribed to correctly it is always a
problem.

For example? What overhead specifically are you talking about? In what
way is using an event significantly more expensive that using an override?

I don't know the full details but you have a delegate involved which is a
seperate object. It needs to enumerate the list of subscribers and call each
one. There are references between these different objects that need to be
cleaned up.

 

[Peter Duniho]

I think it is true. If you override OnLoad then it is unlikely that you will
also use Form_Load. Certainly it is less likely.

If one should always override OnLoad, and when you override OnLoad you
will never use the event, then why does the event exist at all?

You're assuming a properly subscribed event.

And why not? If the original implementation of the class is buggy to
start with, it doesn't really matter how it was implemented at all.

I'm comparing someone
forgetting to call OnLoad to someone who has failed to subscribe to the
event correctly. In the case of failing to call OnLoad it is possible (and
likely) that code will continue to work because the event might not be used.
In the case of the event not being subscribed to correctly it is always a
problem.

Again, that's just not true. Failing to call OnLoad is every bit as
much a problem as failing to raise the event, and for the same reasons.
If you have overridden OnLoad, presumably you did so for a good
reason. If your override is then not called, that's a problem.

Calling OnLoad is not just for the purpose of raising the event. It
surprises me that you wouldn't consider that fact, since you are the one
saying that you should _always_ override OnLoad to implement something
like this.

I don't know the full details but you have a delegate involved which is a
seperate object. It needs to enumerate the list of subscribers and call each
one. There are references between these different objects that need to be
cleaned up.

Well, when you have some actual information that can justify your claim
that there's significantly more overhead using the event than an
override, it would make sense to bring that up as a point. Until then,
it's not a valid point.

Personally, I doubt there is any significant difference.

Pete

 

[Michael C]

Again, that's just not true. Failing to call OnLoad is every bit as much
a problem as failing to raise the event,

Peter, please slow down for a moment and try to read my post. I'm fairly
convinced that you are scanning over what I've written too quickly and
basically getting the completely wrong idea and going off on a tangent.

I'm not talking about failing to raise an event, I'm talking about failing
to *subscribe* to the event, ie the line

this.Load += new whatever

is missing. If you still have the Form_Load routine in your code then it
appears to the programmer that everything is fine. *Every* time this line is
missing it will be a problem. On the other hand if you fail to call OnLoad
in the override this will not be an issue in most cases. This is why I say
the OnLoad is potentially more reliable because if it's there in code then
it is getting called.

Well, when you have some actual information that can justify your claim
that there's significantly more overhead using the event than an override,
it would make sense to bring that up as a point. Until then, it's not a
valid point.

Check google, it is fairly well known that events have a larger overhead.

Personally, I doubt there is any significant difference.

Do as you wish

Michael

 

[Jack Jackson]

If one should always override OnLoad, and when you override OnLoad you
will never use the event, then why does the event exist at all?

Events are there so other objects can be notified of things happening.
The OnXXX methods are there so subclasses can be notified of things
happening more efficiently than by using an event.

 

[Peter Duniho]

Peter, please slow down for a moment and try to read my post.

Right back at you.

I was writing about the two negative outcomes to failing to call the
base class: one is that the OnLoad method itself does not get called;
the other is that failing to call the base OnLoad also results in a
failure for the event to be raised.

Somehow, you seem to have missed this point.

I'm fairly
convinced that you are scanning over what I've written too quickly and
basically getting the completely wrong idea and going off on a tangent.

Yes, I can see that you are convinced. If you would spend a little more
time reading my post rather than just assuming I'm blowing you off, you
might not be so convinced.

I'm not talking about failing to raise an event, I'm talking about failing
to *subscribe* to the event, ie the line

this.Load += new whatever

I know.

is missing. If you still have the Form_Load routine in your code then it
appears to the programmer that everything is fine. *Every* time this line is
missing it will be a problem. On the other hand if you fail to call OnLoad
in the override this will not be an issue in most cases. This is why I say
the OnLoad is potentially more reliable because if it's there in code then
it is getting called.

And my point is that there are really two parts to this question: is the
original implementation correct? And is a derived implementation correct?

Answering the first part is easy: either it works or it doesn't. If you
properly subscribe to the event, you're fine. Since you made the
original design decision to subscribe rather than override, presumably
it is trivial to subscribe correctly.

Answer the second part is harder, because you are not in control of the
derived implementation at the point in time that you write the base
implementation. But as far as that goes, the derived implementation can
mess up either the event-based implementation or the override based
implementation, and it will mess them both up in the same way: it will
fail to call the base class's method.

This originally came up in the context of you claiming that even though
the programming errors involved are "possibly both equally likely", that
it was the case that "The event is a problem in 100% of cases where the
override might be a small percentage".

You have yet to post something that explains exactly what percentages
you're talking about, never mind explains the math involved.

Check google, it is fairly well known that events have a larger overhead.

I checked Google, and it had nothing to say on the topic that supports
your claim.

If you want to make a claim, back it up. If you can't back it up, then
you have no business making the claim. And no, saying "look it up" is
not backing up the claim. If you yourself cannot readily provide the
references to justify the claim, then you yourself do not have the
first-hand knowledge required to legitimately make the claim.

Pete