Click here to Skip to main content
Click here to Skip to main content

ASP.NET controls - How controls are related to each other

, 14 Mar 2007
Rate this:
Please Sign up or sign in to vote.
This is another small article on my series about ASP.NET controls, and its main focus is to reveal how controls are related to each other, which entities are involved, and what their main roles in this task are.

Introduction

This is another small article on my series about ASP.NET controls, and its main focus is to reveal how controls are related to each other, which entities are involved, and what are their main roles in this task.

Motivation

Understanding the small pieces of magic that happen underneath our noose every time a Page request is handled and someone gets your web form in his browser will help you avoid many problems, to debug them faster, and to produce better applications.

If you're an experienced programmer, this knowledge may also help you to orchestrate complex workarounds and perhaps step through some of the ASP.NET constraints.

How controls are related to each other?

In order to expose an ASP.NET form, you need to place it in a Page, in fact, in any ASP.NET Control. In order to participate in the Page lifecycle, you need to be somehow related to the Page. This relation is achieved by a parent/children hierarchical structure.

The Page control is the root control of this hierarchical relationship, and is the one that handles which pipeline should be triggered (initial request, a postback request, or a callback request).

A control can, if needed, contain other controls, and all those child controls are kept together in a ControlCollection instance that is exposed through the Controls property. Every control knows its Parent Control.

A control that can contain other controls can also be marked as a participant in the automatic naming generation process of its descendents. This role is achieved by implementing the INamingContainer interface, and when this happens, the control is said to be a NamingContainer. Every child control will know its NamingContainer.

The ControlCollection provides the usual set of methods for collection management:

  • Add - Adds the specified Control object to the collection.
  • Remove - Removes the specified server control from the parent server control's ControlCollection object.
  • Clear - Removes all controls from the current server control's ControlCollection object.

A control can only be attached to another and become its child through the ControlCollection.Add method. Every time a control is added or removed from a collection, both its parent and its NamingContainer are notified and will react.

When a control is added to another control's children collection, the new parent Control.AddedControl method is invoked and the following steps are taken:

  1. Check if the newly added child control has an owner and therefore if its use is restricted only to that owner control. If true, the child is not a valid control and an exception is thrown.
  2. Check if the newly added child control belongs to another control's children collection, and in that case, the control will be removed from its previous parent's children collection. This is required to ensure a valid hierarchical relationship: a control can only belong to a single ControlCollection.
  3. Update the Page reference of the newly added child control to reference the new parent Page.
  4. Update the parent reference of the newly added child control to reference itself. If the new parent control is a NamingContainer, then we will update the NamingContainer reference of the newly added child control to reference itself.
  5. If the new child control ID has not been specified, then a new ID is automatically generated for the NamedControls collection of the new child control, and the NamingContainer is marked as dirty to ensure that a new and fresh collection is created and populated.
  6. If possible, the control life cycle is recreated for the newly added child control.

When a control is removed from its parent ControlCollection, the parent Control.RemovedControl method is invoked and the following steps are taken:

  1. Check if the newly added child control has an owner and therefore if its use is restricted only to that owner control. If true, the child is not a valid control and an exception is thrown.
  2. The NamedControls collection of the child control NamingContainer is marked as dirty to ensure that a new and fresh collection is created and populated (without the removed control).
  3. The child control performs an UnloadRecursive without disposing.
  4. All references set at AddedControl are removed and the control is released from any hierarchy.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Nuno M. F. Gomes
Software Developer (Senior)
Portugal Portugal
Nuno Gomes currently works as a Senior Developer for one of the major portuguese banks.
 
Gomes graduated from Instituto Superior Tecnico with a Electronics and Computers degree in 1999.
 
His daily work main focus is, since 2003, on ASP.NET. A true .NET developer with great passion for the simple solution.

Comments and Discussions

 
QuestionHow about retrieving child UserControl's data? Pinmemberxvietntx20-Mar-07 16:55 
AnswerRe: How about retrieving child UserControl's data? PinmemberNuno M. F. Gomes22-Mar-07 14:25 
First of all, I must aware you that creating dynamic controls may lead you to some unexpected results.
The most common mistake is assuming that once created, a dynamic control will be automatically recreated on every consecutive post, in fact, due to Web paradigm all controls must be recreated in order to participate in the Request Page life cycle.
What ASP.NET does, is to execute this task automatically for us, but only for controls declared in markup, all other controls must be recreate by programmer.
Another issue is expecting that, with some kind of magic, the controls created dynamically in a previous request behave the same way as declared controls. In order to achieve this transparency the dynamic created controls must:
  • 1. be added always to the same parent control and exactly in the same order
  • 2. be added during Init or Load stages of Page Life Cycle
If the first goal is not achieved then the following problems may occur:
  • 1. events wont be triggered
  • 2. mistaken triggers (only if mistaken controls have the same type )
  • 3. application may simply throw a mismatch ViewState exception.
If the second goal is not respected then dynamic created controls will render normally but they will never trigger any OnChange or OnClick event type. Why? Simply because Page pipeline only try find posted ids twice: one after OnInitComplete and another after OnLoadComplete.
 
Now, answering your question, the best way to find a particular control is by ID using parentControl.FindControl(child.ID) but in order to use this you must set a different ID for every control.
If you do not know the child ID but somehow you know its index position on parent control Controls collection then use parentControl.Controls[idx].
If you don’t know either ID or Controls Collection index then the only way is doing an iteration through the parent Controls Collection using a simple foreach(Control c in parentControl.Controls){[…]}.

 

 
Nuno Gomes
Portugal - Europe's West Coast

GeneralRe: How about retrieving child UserControl's data? Pinmemberxvietntx22-Mar-07 16:31 
Questionhow about to Windows Controls? PinmemberSouthmountain14-Mar-07 6:18 
AnswerRe: how about to Windows Controls? [modified] PinmemberNuno M. F. Gomes14-Mar-07 7:00 
GeneralRe: how about to Windows Controls? PinmemberPaulo Morgado25-Mar-07 23:49 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.140827.1 | Last Updated 14 Mar 2007
Article Copyright 2007 by Nuno M. F. Gomes
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid