Dynamically Created Controls - Common Pitfalls 2

[DaZZleD]

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:

Trace Information
Category                      Message
aspx.page                     Begin Init
aspx.page                     End Init
aspx.page                     Begin LoadViewState
aspx.page                     End LoadViewState
[b]aspx.page                     Begin ProcessPostData
aspx.page                     EndProcessPostData
                              Page_Load
aspx.page                     Begin ProcessPostData Second Try
aspx.page                     End ProcessPostData Second Try[/b]
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";
       PlaceHolder1.Controls.Add(TextBox2);
}

private void Page_Load(object sender, System.EventArgs e)
{
       TextBox3 = new TextBox();
       TextBox3.ID = "TextBox3";
       PlaceHolder1.Controls.Add(TextBox3);

       if (Page.IsPostBack)
       {
              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
        TextBox3.Text =

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.

--------------------------
"two wrongs don't make a right, but three lefts do" - the unknown sage