Working With Dynamic Controls


One big advantage of ASP.NET pages is the ability to get powerful application functionality without writing a lot of code. By simply including the tag for the server control on the page, the control is automatically instantiated by the ASP.NET run time, the view state is managed, and the control’s events are fired. Of course, sometimes you won’t know that a control or set of controls will be needed until the page is running. We can declare the controls and set the Visible property to false when the controls aren’t needed, but there is performance overhead associated with a control as long as it exists. Alternatively, a control can be created dynamically and added to the control tree.

When working with dynamically created controls, you must add them back to the control tree early enough in the page life cycle to effectively participate in postback. Use the Init method on the page to create these controls. The controls will then be able to manage events just as though they were placed on the page declaratively.

Another challenge when working with controls dynamically is remembering information about the dynamic controls. Of course, the view state of the controls themselves will function in the same way as static controls, but you might need information about which controls need to be created during postback. The dynamic controls must be created for the postback processing to handle the view state information they stored in the previous request. Code Listing 1-16, DynamicTextbox.aspx, demonstrates creating a Textbox control during the initial request. We record the fact that the control was created in the page view state. During the postback, we examine that stored information, which lets us know that we need to recreate that type of control so that it is part of the control tree and can handle the view state information that it saved previously.

Code Listing 1-16: DynamicTextbox.aspx

start example
 <%@Page language="C#" debug="true" %>
<script runat="server" language="C#">
protected void Page_Init(object o, EventArgs e) {
if(!IsPostBack) {
CreateTextBox();
}
else {
if(shouldCreateTextBox == true) {
CreateTextBox();
}
}
}

protected override void LoadViewState(object savedState) {
if(savedState != null) {
object[] state = (object[])savedState;
base.LoadViewState(state[0]);
shouldCreateTextBox = (bool)state[1];
}
}

protected override object SaveViewState() {
object[] state = new object[2];
state[0] = base.SaveViewState();
state[1] = shouldCreateTextBox;
return state;
}

private void CreateTextBox() {
TextBox t = new TextBox();
theForm.Controls.Add(t);
shouldCreateTextBox = true;
}

private static bool shouldCreateTextBox = false;
</script>
<form runat="server" >
<asp:button runat="server" type="Submit" Text="Go" />
</form>
end example

The page view state is automatically sent to the client for us and posted back to the server on the subsequent request. (We’ll look at this in more detail in Chapter 2 when we discuss how server controls work.) In this example, we are overriding the methods to add and retrieve our own piece of state information and then delegating to the base class implementations to take care of the rest of the state. There is no <asp:textbox> in the page itself, yet the textbox is present in the rendered output; if you enter data in it and perform a postback, it tracks the posted data between requests. The textbox works normally because the code in the page creates it and adds it to the Controls collection of the form, based on the value stored in the page view state.




Microsoft ASP. NET Coding Strategies with the Microsoft ASP. NET Team
Microsoft ASP.NET Coding Strategies with the Microsoft ASP.NET Team (Pro-Developer)
ISBN: 073561900X
EAN: 2147483647
Year: 2005
Pages: 144

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net