Browse DevX
Sign up for e-mail newsletters from DevX


Dynamically Adding Wired Controls to Web Forms : Page 2

Dynamically creating Web controls and adding them to a Web Form can be a challenging process. A thorough understanding of how the ASP.NET engine instantiates controls as well as the event life cycle of Web Forms is crucial to success.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

The Page Event Life Cycle
This is where a thorough understanding of the page event life cycle comes into play. ASP.NET differs from classic ASP in many ways, one of which is the way in which client-side interaction is handled once you submit it back to the server. In classic ASP, the developer handled this process, which meant that the server handled each page in a unique manner. ASP.NET changed this by imposing a structured event life cycle that introduced a uniform series of function members (methods) that are executed consistently each and every time that it renders a Web Form. The function members that handle events are listed and described in Table 1 in the order in which they are processed.

Function Member



Handles the Init event and initializes the Web Form and all of the controls contained on it.


The ViewState property of all of the server controls are updated to reflect the state of the controls being received from the client. ASP.NET uses the ViewState setting of each control to determine which control values have been modified.


Process incoming form data.


This is the most commonly used function member in the entire cycle. Controls are created, initialized, and the state is restored.


When the state of a control changes, events for each control are fired in response to the data change. These events are fired here.


The event that caused the postback is fired.


This is the last opportunity to interact with controls and form data prior to it being rendered and sent to the client.


The state of all controls is saved to the encrypted ViewState string that is stored in the hidden control and persisted to the client.


The output of the Web Form is rendered to be sent to the client.


Final cleanup opportunity.


All server-side references to controls and the page itself are unloaded from memory.

By far, the most commonly used function member listed in Table 1 is the OnLoad() function member. In fact, when you create any type of ASP.NET Web item such as a Web Form or a Web user control, Visual Studio .NET automatically adds this function member to the code behind class for you, whereas you must manually add (override) most of the other function members. In this function member, the current values of the controls on the Web Form are available and code may interact directly with them. Let me state a few very important observations in relation to dynamically created controls.

You can only wire events into controls in either the OnInit() function member or the OnLoad() function member; if the control is dependant upon data on the Web Form, then the OnLoad() method is the only option.
You can dynamically create controls and wire events into them at any point in the execution process. However, you can only wire events into a control in either the OnInit() function member or in the OnLoad() function member. If the events are encountered at any other point in the cycle of events, it will not cause an exception to be thrown but it will have no affect on the control. The code snippet below shows an example of wiring an event into a control in the OnInit() function.

   // Override the OnInit() method.
   override protected void OnInit(EventArgs e)
     // Dynamically create controls that do not
     // depend upon data on the Web Form.
     Button companyDetailsButton = new Button();
     companyDetailsButton.Click += new EventHandler(this.ShowDetailAccounting);

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date