Use Form Constructor or Load event?

[garyusenet@myway.com]

I was originally taught to double click the form, to get to the load
event handler and in there put anything I want to happen when my form
is opened.

However, today whilst reorganising some code for clarity it struck me
that I could just have well put this code in the forms constructor. The
code simply populates text boxes etc... on the form with values.

So i wondered as a rule of thumb is it generally better to do things
like populating text boxes on the form in the forms constructor, or in
the forms load event?

Thanks for your thoughts,

Gary-

[Joanna Carter [TeamB]]

Re: Use Form Constructor or Load event?

<garyusenet@myw ay.coma écrit dans le message de news:
1168009670.0377 75.85480@s34g20 00...legro ups.com...

|I was originally taught to double click the form, to get to the load
| event handler and in there put anything I want to happen when my form
| is opened.
|
| However, today whilst reorganising some code for clarity it struck me
| that I could just have well put this code in the forms constructor. The
| code simply populates text boxes etc... on the form with values.
|
| So i wondered as a rule of thumb is it generally better to do things
| like populating text boxes on the form in the forms constructor, or in
| the forms load event?

If you want to be a mouse jockey, then you use event handlers for
everything. However, when you learn to be a real programmer with OO skills,
then you tend to use the constructors and methods of the form classes just
like you would in any other, 'non-visual' class.

Your question indicates that you are no longer content with simply riding a
mouse :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Scott M.]

Re: Use Form Constructor or Load event?

You can't put code that refers to the form's controls in the form's
constructor because, at that point in the construction process, the form's
controls don't exist yet. That's why the load event is so much more
commonly used, at that point, the form and its constituent controls are all
instantiated and ready to be accessed.



<garyusenet@myw ay.comwrote in message
news:1168009670 .037775.85480@s 34g2000cwa.goog legroups.com...

>I was originally taught to double click the form, to get to the load
event handler and in there put anything I want to happen when my form
is opened.
>
However, today whilst reorganising some code for clarity it struck me
that I could just have well put this code in the forms constructor. The
code simply populates text boxes etc... on the form with values.
>
So i wondered as a rule of thumb is it generally better to do things
like populating text boxes on the form in the forms constructor, or in
the forms load event?
>
Thanks for your thoughts,
>
Gary-
>

[Dustin Campbell]

Re: Use Form Constructor or Load event?

Hi Gary,

You can place code that accesses the components on your form in the constructor
provided that it is after the call to InitializeCompo nent within your constructor.
That's the call that creates of all controls on the form and sets their properties.
However, occassionally you'll run into an action (more often with third-party
controls) that can only be done in the Form_Load event. For example, I was
working with a third-party control that provided methods to save and restore
the state of the control. I found that the best place to call the restore
method was from the Load event (didn't work in the constructor) and the best
place to call the save method was from the Closing event. So, go ahead and
use the constructor but tuck the knowledge of the Load event away in case
you run into some odd control that requires this at some point. Personally,
I tend to just use the Load event just to be on the safe side. As Joanna
implied, you could also override the Form's OnLoad method.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Marc Gravell]

Re: Use Form Constructor or Load event?

You can't put code that refers to the form's controls in the form's

constructor because, at that point in the construction process, the
form's controls don't exist yet.

Not entirely true; as long as your code *follows* InitialiseCompo nent,
then they should exist. Unless you currently use the Load event to
create them, but that isn't the IDE's approach...

Marc

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

Re: Use Form Constructor or Load event?

Hi,

<garyusenet@myw ay.comwrote in message
news:1168009670 .037775.85480@s 34g2000cwa.goog legroups.com...

>I was originally taught to double click the form, to get to the load
event handler and in there put anything I want to happen when my form
is opened.
>
However, today whilst reorganising some code for clarity it struck me
that I could just have well put this code in the forms constructor. The
code simply populates text boxes etc... on the form with values.
>
So i wondered as a rule of thumb is it generally better to do things
like populating text boxes on the form in the forms constructor, or in
the forms load event?

I tend to create a method to do that, or in another word a method to refresh
the interface. Inside the method I will populate the controls as they should
be in the initial state.

From where I call it initialy depends, I try to call it from the
constructor, but sometimes I just do the double click :) and it ends in the
Form_Load method.
Just remember that in the constructor it should be AFTER the
InitializeCompo nent() call

Also note that the Load event only runs once (as the contructor), if the
form is hidden and shown again the Load is not fired.



--
Ignacio Machin
machin AT laceupsolutions com

[Christof Nordiek]

Re: Use Form Constructor or Load event?

Additinal to what others said:
You should put code in the Load event, if it shouldn't run in design mode
because the DesignMode property doesn't work in the constructor.
But this more refers to controls then to forms; for forms this only matters,
if you want to derive from that form via the forms designer.

<garyusenet@myw ay.comschrieb im Newsbeitrag
news:1168009670 .037775.85480@s 34g2000cwa.goog legroups.com...

>I was originally taught to double click the form, to get to the load
event handler and in there put anything I want to happen when my form
is opened.
>
However, today whilst reorganising some code for clarity it struck me
that I could just have well put this code in the forms constructor. The
code simply populates text boxes etc... on the form with values.
>
So i wondered as a rule of thumb is it generally better to do things
like populating text boxes on the form in the forms constructor, or in
the forms load event?
>
Thanks for your thoughts,
>
Gary-
>

[Scott M.]

Re: Use Form Constructor or Load event?

Yes, entirely true since the constructor is the very first event to fire.

"Marc Gravell" <marc.gravell@g mail.comwrote in message
news:%23Tt04AOM HHA.1008@TK2MSF TNGP06.phx.gbl. ..

>You can't put code that refers to the form's controls in the form's
>constructor because, at that point in the construction process, the
>form's controls don't exist yet.

>
Not entirely true; as long as your code *follows* InitialiseCompo nent,
then they should exist. Unless you currently use the Load event to create
them, but that isn't the IDE's approach...
>
Marc
>

[Marc Gravell]

Re: Use Form Constructor or Load event?

I'm afraid that I am going to have to argue with you here. Read again:
*follows* InitialiseCompo nent [sic; pick "s" or "z" as you like]. In
IDE genereated classes (as suggested by the OP), then it is
InitializeCompo nent that creates the .Net classes representing the
controls, intialises the backing fields, and adds the controls to the
Controls collection. As such, in pretty much every way that matters
(for general coding) those controls now exist fully in a .Net sense,
and can be fully manipulated as required. The only thing that doesn't
(by default) exist at this point is the Win32 handles, but this is not
required for most functions (hooking events, changing properties etc).
So OK: you wouldn't be able to do backhand PInvoke on the controls yet,
and you won't be able to call BeginInvoke, but I don't recall that
being suggested.

Marc