One of the main critera is for a "server control" to qualify as a server control, the class must inherit from System.Web.UI.Control class, directly or indirectly. Another main critera for one to qualify as a server control is the ability to output some type of text into the HTTP request; either or all of the following:

• Client side scripts.
• Html mark-up.
• Contain other server controls as children.

With that said, time for you to swallow the big red pill – a page (the one at System.Web.UI.Page) is a server control as well. It does qualify for both of the main criterion. Think that you got a fright when you read that a page is a server control? Then just read on...

Lets add more complexity - every ounce of text and “static” HTML is a server control as well. Here is the interesting part – text can defy this behaviour (get converted to a server control) can be manipulated so that the text can become part of the control (known as extended or advanced properties). With the text out of the way (either a server control or part of a server control), the page parser finalizes the page.

When the page is being finalized the following will occur - all controls that contain other controls are then sorted into the parent-children relationship (the parents are also known as container controls). To accomplish this, AddParsedSubObject method is then used by the page parser. By default, the method will take the instance of the control (that was found "underneath" the current control) and then cast it as a Control class. This method will then take the control and then place it under a ControlCollection class - namely, the Controls property.

While the AddParsedSubObject method is being executed (adding the controls from the page parser), the ControlCollection class is doing what its constructor asked for the instaintation to create the ControlCollection – telling the new controls who their “parent” is. This is required by unique identification of the controls for various reasons. The page parser works from the top of the page hierarchy and works “deeper” into the control tree - moving in a left to right and a top to bottom fashion.

When those controls gets its content "underneath" themselves, the process started all over again until the entire page has been parsed. Now the Page is ready to begin its life cycle.

As we go across more articles in the series, we will pick up other essential bits and pieces that makes a control, a control (no pun intended). Although I did explain this section in a very brief manner, there is nothing really to lure on about the internal workings of the user interface in ASP.NET.