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]]

Re: Form_Load vs Constructor

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 InitializeCompo nent 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.

--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard. caspershouse.co m

"Smithers" <A@B.comwrote in message
news:uOM27PS1HH A.5772@TK2MSFTN GP02.phx.gbl...

>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.
>

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

Re: Form_Load vs Constructor

Hi,

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

"Smithers" <A@B.comwrote in message
news:uOM27PS1HH A.5772@TK2MSFTN GP02.phx.gbl...

>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.
>

[Michael C]

Re: Form_Load vs Constructor

"Smithers" <A@B.comwrote in message
news:uOM27PS1HH A.5772@TK2MSFTN GP02.phx.gbl...

>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: Form_Load vs Constructor

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" <nospam@nospam. comwrote in message
news:%23rD1Ns71 HHA.1124@TK2MSF TNGP06.phx.gbl. ..

"Smithers" <A@B.comwrote in message
news:uOM27PS1HH A.5772@TK2MSFTN GP02.phx.gbl...

>>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
>

[Michael C]

Re: Form_Load vs Constructor

"Smithers" <A@B.comwrote in message
news:O0K1lJQ2HH A.1208@TK2MSFTN GP05.phx.gbl...

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]

Re: Form_Load vs Constructor

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:

>- - 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.

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"


"Michael C" <nospam@nospam. comwrote in message
news:eNr6vuU2HH A.464@TK2MSFTNG P02.phx.gbl...

"Smithers" <A@B.comwrote in message
news:O0K1lJQ2HH A.1208@TK2MSFTN GP05.phx.gbl...

>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
>notification s"

>
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
>

[Jack Jackson]

Re: Form_Load vs Constructor

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.

On Tue, 7 Aug 2007 17:03:04 -0700, "Smithers" <A@B.comwrote :

>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
>notification s, it can use the override instead>>
>Yes, of course, but what does this have to do with the OP?
>
>RE:

>>- - 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.

>
>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"
>
>
>"Michael C" <nospam@nospam. comwrote in message
>news:eNr6vuU2H HA.464@TK2MSFTN GP02.phx.gbl...

>"Smithers" <A@B.comwrote in message
>news:O0K1lJQ2H HA.1208@TK2MSFT NGP05.phx.gbl.. .

>>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
>>

>

[Peter Duniho]

Re: Form_Load vs Constructor

Smithers wrote:

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]

Re: Form_Load vs Constructor

"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:13bi3pgm23 ilodb@corp.supe rnews.com...

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

[Peter Duniho]

Re: Form_Load vs Constructor

Michael C wrote:

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

[Peter Duniho]

Re: Form_Load vs Constructor

Michael C wrote:

[...]

>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).

>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.

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?

>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.

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]

Re: Form_Load vs Constructor

"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:13biqb0k9h fpgc3@corp.supe rnews.com...

>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.

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.

>
Pete

[Peter Duniho]

Re: Form_Load vs Constructor

Michael C wrote:

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?

>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.

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.

>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.

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]

Re: Form_Load vs Constructor

"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:13bvnk7h08 sjh63@corp.supe rnews.com...

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