New to creating Server Controls. Have some questions.

[Ken Varn]

I am just starting the process of creating ASP.NET server controls. I have
created controls for .NET applications, but have just started with ASP.NET.
I am a little confused about some areas that I am hoping someone can help
clear up.

1. What is the difference between initializing a control in the
constructor, vs the OnInit(), vs the CreateChildControls() methods?
2. The control that I created contains an Items collection attribute that I
implemented. I am using the base WebControl class for my control and
constructed it using the DIV type. I noticed that the Items attribute was
rendered to the web page as a Items="(Collection)" attribute. Why and how
does the base class know to add this to the attribute of the <DIV> tag?
What is the significance of setting this attribute since the state of the
data is not preserved?
3. I implemented the data postback interface and registered it using
RegisterRequiresPostback(). When using the debugger, I notice that the
LoadPostData method is called prior to calling the OnInit() method. Why is
this? I would expect the OnInit() method be called first?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------

 

[Matt Hawley]

Hi Ken,

1. You should always create your controls in the CreateChildControls method per best practices. If for some reason you need to access control properties prior to the OnInit method (which is possible), you're controls need to be there, and as such...if you call this.EnsureChildControls(), it will make sure that CreateChildControls is called. An example of this is if you're creating a composite control, and you need to access child properties of a control prior to OnInit being called. In your get property, you do a EnsureChildControls(), and then reference the control's property.

2. You shouldn't be seeing this in your HTML. There are certain attributes you need to apply to your collection's property that will make it do what you wish. Here's an example:

[Bindable(false),
Browsable(false),
Category("Appearance"),
DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public virtual HolidayCollection Holidays { ... }

If you're creating a custom collection, that collection will need to store its viewstate, and you'll need to manually store/load viewstate for that collection using the LoadViewState and SaveViewState methods.

3. Going back to my comment for 1, you should never use OnInit unless you really, really needed to. You should use CreateChildControls. The reason it is calling prior to that, is because its loading the post data, which you need prior to LoadViewState so the correct data is represented in the control. If OnInit were called before hand, you would have "old" data when trying to work with it. Do you understand?

Matt Hawley, MCAD .NET
http://www.eworldui.net

I am just starting the process of creating ASP.NET server controls. I have
created controls for .NET applications, but have just started with ASP.NET.
I am a little confused about some areas that I am hoping someone can help
clear up.

1. What is the difference between initializing a control in the
constructor, vs the OnInit(), vs the CreateChildControls() methods?
2. The control that I created contains an Items collection attribute that I
implemented. I am using the base WebControl class for my control and
constructed it using the DIV type. I noticed that the Items attribute was
rendered to the web page as a Items="(Collection)" attribute. Why and how
does the base class know to add this to the attribute of the <DIV> tag?
What is the significance of setting this attribute since the state of the
data is not preserved?
3. I implemented the data postback interface and registered it using
RegisterRequiresPostback(). When using the debugger, I notice that the
LoadPostData method is called prior to calling the OnInit() method. Why is
this? I would expect the OnInit() method be called first?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------

 

[Ken Varn]

So, it sounds like the class constructor on a server control should not be
used for any initialization in ASP.NET?

Also, in regards to #3, I am still a little confused. I am assuming that
all class data objects must be reconstructed somehow on the postback. If
that includes instantiating objects that are part of that class, then
wouldn't that have to be done in the OnInit() call first? Otherwise, the
class member objects would be invalid when trying to supply data to them in
the LoadPostData() method. So, I am not sure where I should be newing my
class objects. Should I call EnsureChildControls() in my LoadPostData()
method?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------

Hi Ken,

1. You should always create your controls in the CreateChildControls

method per best practices. If for some reason you need to access control
properties prior to the OnInit method (which is possible), you're controls
need to be there, and as such...if you call this.EnsureChildControls(), it
will make sure that CreateChildControls is called. An example of this is if
you're creating a composite control, and you need to access child properties
of a control prior to OnInit being called. In your get property, you do a
EnsureChildControls(), and then reference the control's property.

2. You shouldn't be seeing this in your HTML. There are certain

attributes you need to apply to your collection's property that will make it
do what you wish. Here's an example:

[Bindable(false),
Browsable(false),
Category("Appearance"),
DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public virtual HolidayCollection Holidays { ... }

If you're creating a custom collection, that collection will need to

store its viewstate, and you'll need to manually store/load viewstate for
that collection using the LoadViewState and SaveViewState methods.

3. Going back to my comment for 1, you should never use OnInit unless you

really, really needed to. You should use CreateChildControls. The reason
it is calling prior to that, is because its loading the post data, which you
need prior to LoadViewState so the correct data is represented in the
control. If OnInit were called before hand, you would have "old" data when
trying to work with it. Do you understand?

 

[Matt Hawley]

Ken,

Thats right, you should avoid using a constructor or OnInit method to instantiate your controls.

I cant argue why MS did it this way, its just the way it is...and it was probably due to how most developers would code. I know I would hate getting "old" data in my OnInit (or the Init event) method, because it wouldn't be viable data I could program against. That is the reason it was done in that manner.

It wouldn't hurt calling EnsureChildControls() in your LoadPostData, this will ensure that they've been created and added in the same manner prior to a postback. Note, if the CreateChildControls has previously been called (either by you, or the framework), successively calling EnsureChildControls will not call CreateChildControls.

Matt Hawley, MCAD .NET
http://www.eworldui.net

So, it sounds like the class constructor on a server control should not be
used for any initialization in ASP.NET?

Also, in regards to #3, I am still a little confused. I am assuming that
all class data objects must be reconstructed somehow on the postback. If
that includes instantiating objects that are part of that class, then
wouldn't that have to be done in the OnInit() call first? Otherwise, the
class member objects would be invalid when trying to supply data to them in
the LoadPostData() method. So, I am not sure where I should be newing my
class objects. Should I call EnsureChildControls() in my LoadPostData()
method?

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------

Hi Ken,

1. You should always create your controls in the CreateChildControls

method per best practices. If for some reason you need to access control
properties prior to the OnInit method (which is possible), you're controls
need to be there, and as such...if you call this.EnsureChildControls(), it
will make sure that CreateChildControls is called. An example of this is if
you're creating a composite control, and you need to access child properties
of a control prior to OnInit being called. In your get property, you do a
EnsureChildControls(), and then reference the control's property.

2. You shouldn't be seeing this in your HTML. There are certain

attributes you need to apply to your collection's property that will make it
do what you wish. Here's an example:

[Bindable(false),
Browsable(false),
Category("Appearance"),
DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public virtual HolidayCollection Holidays { ... }

If you're creating a custom collection, that collection will need to

store its viewstate, and you'll need to manually store/load viewstate for
that collection using the LoadViewState and SaveViewState methods.

3. Going back to my comment for 1, you should never use OnInit unless you

really, really needed to. You should use CreateChildControls. The reason
it is calling prior to that, is because its loading the post data, which you
need prior to LoadViewState so the correct data is represented in the
control. If OnInit were called before hand, you would have "old" data when
trying to work with it. Do you understand?