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 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]
- mv*@spam.guard. caspershouse.co m

"Smithers" <[e-mail] in message
news:uO******** ******@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 \)]

Hi,

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

"Smithers" <[e-mail] in message
news:uO******** ******@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]

"Smithers" <[e-mail] in message
news:uO******** ******@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:
<< 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" <no****@nospam. comwrote in message
news:%2******** ********@TK2MSF TNGP06.phx.gbl. ..

"Smithers" <[e-mail] in message
news:uO******** ******@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]

"Smithers" <[e-mail] in message
news:O0******** ******@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]

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" <no****@nospam. comwrote in message
news:eN******** *****@TK2MSFTNG P02.phx.gbl...

"Smithers" <[e-mail] in message
news:O0******** ******@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]

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" <[e-mail] :

>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" <no****@nospam. comwrote in message
news:eN******* ******@TK2MSFTN GP02.phx.gbl...

>"Smithers" <[e-mail] in message
news:O0******* *******@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]

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]

"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:13******** *****@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