INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS
Come Join Us!
Are you a
Computer / IT professional?
Join Tek-Tips now!
- Talk With Other Members
- Be Notified Of Responses
To Your Posts
- Keyword Search
- One-Click Access To Your
- Automated Signatures
On Your Posts
- Best Of All, It's Free!
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.
Partner With Us!
"Best Of Breed" Forums Add Stickiness To Your Site
(Download This Button Today!)
"...A lot of the information I've found at this site would've taken me forever if I'd have attempted to research it on my own. Thanks again."
Where in the world do Tek-Tips members come from?
Dynamically Created Controls - Common Pitfalls
Posted: 24 Nov 04
Special thanks to Denis Bauer for extra information about this.
1. With ASP.NET you have two options to create controls on a web form: declaratively within the HTML code or dynamically at runtime. While the first one is much more common, the second options is especially helpful in scenarios where the page content changes dependent on some parameters like the user requesting the page, the language etc.
In this mini-article I will try to cover some of the common pitfalls of using dynamically created controls that come to bother almost every ASP.NET programmer.
2. Common pitfalls
2.1 Recreating the controls for each roundtrip
The first problem, developers face using dynamically created controls is that they are not persisted or recreated automatically between roundtrips. So it is the developer’s task to rebuild the control structure.
Why should he do this? Consider this: we have a button for example that is created dynamically and that has an event wired to it. What happens if the button is not recreated on Page_Load? The event won't fire because the ASP.NET would look for a control with the same ID that would not exist, so it won't call the function that handles the event.
2.2 Events are not raised because the control IDs change
When a new control is added to the control collection that doesn’t have an ID, ASP.NET automatically takes one from the ID pool that each control has. This ID normally consists of the string “__ctl” and a continuous counter. Therefore, if the order of the control tree differs between two postbacks the automatically assigned IDs might change. This effect doesn’t influence ViewState restoration as it relies on indexes instead of IDs but it does affect post data and postback processing.
This might cause the post back information of a control to be lost, or event worse, passed to another control. If we have two controls (a TextBox and a Button) that are dynamically created but are added once in one order and then in reverse order, the Text property of the TextBox resulted from the post back would be set as the Text property of the Button, while the click event of the Button would not fire at all.
2.3 Postdata processing in the second try
Another issue when working with dynamic controls is the delayed restoration of the Postdata. Postdata commonly refers to the form values that are sent from the client to the server via the HTTP POST command like the entered values in the textboxes or selected items of the radio buttons.
In ASP.NET these values are automatically written back to the control’s properties immediately before Page_Load in a phase called “ProcessPostData”. For static controls this is no problem as they already exist but dynamic controls are often created in Page_Load. Therefore in ProcessPostData the values cannot be restored. To work around this problem ASP.NET keeps track of which values could not be processed and starts a “ProcessPostData Second Try” directly after Page_Load. For further reference turn on tracing which looks like this:
aspx.page Begin Init
aspx.page End Init
aspx.page Begin LoadViewState
aspx.page End LoadViewState
aspx.page Begin ProcessPostData
aspx.page Begin ProcessPostData Second Try
aspx.page End ProcessPostData Second Try
aspx.page Begin Raise ChangedEvents
aspx.page End Raise ChangedEvents
aspx.page Begin Raise PostBackEvent
aspx.page End Raise PostBackEvent
aspx.page Begin PreRender
aspx.page End PreRender
aspx.page Begin SaveViewState
aspx.page End SaveViewState
aspx.page Begin Render
aspx.page End Render
What does this mean in practice?
// TextBox1 is declared in ASPX file
protected System.Web.UI.WebControls.TextBox TextBox1;
protected System.Web.UI.WebControls.TextBox TextBox2;
protected System.Web.UI.WebControls.TextBox TextBox3;
private void Page_Init (object sender, System.EventArgs e)
TextBox2 = new TextBox();
TextBox2.ID = "TextBox2";
private void Page_Load(object sender, System.EventArgs e)
TextBox3 = new TextBox();
TextBox3.ID = "TextBox3";
Trace.Write("TextBox1.Text = " + TextBox1.Text);
Trace.Write("TextBox2.Text = " + TextBox2.Text);
Trace.Write("TextBox3.Text = " + TextBox3.Text);
// (1) this text is never displayed, because it is
//overwritten in ProcessPostData Second Try
TextBox3.Text = "Hello World";
Take a look at the sample above and compare the behaviour of the three textboxes. TextBox1 is created statically and its Postdata can be accessed in Page_Load. TextBox3 is created dynamically in Page_Load and its Postdata are not directly available. TextBox2 is created dynamically as well but already in Page_Init. So its values can be restored in ProcessPostData (First Try) and are available in Page_Load.
TextBox1.Text = TB1
TextBox2.Text = TB2
A problem occurs when trying to change the value of TextBox3 in Page_Load as demonstrated in (1) because it is overwritten in ProcessPostData Second Try.
Back to Microsoft: ASP.NET FAQ Index
Back to Microsoft: ASP.NET Forum
Join Tek-Tips® Today!
Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.
Here's Why Members Love Tek-Tips Forums:
- Talk To Other Members
- Notification Of Responses To Questions
- Favorite Forums One Click Access
- Keyword Search Of All Posts, And More...
Register now while it's still free!
Already a member? Close this window and log in.
Join Us Close