Dynamically Created Controls - Common Pitfalls (动态控件易出现的问题)

Dynamically Created Controls - Common Pitfalls faq855-5550 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: CODE Trace Information Category                      Message aspx.page                     Begin Init aspx.page                     End Init aspx.page                     Begin LoadViewState aspx.page                     End LoadViewState aspx.page                     Begin ProcessPostData aspx.page                     EndProcessPostData                               Page_Load 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? CODE // 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. CODE         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.