TextBox1=text&DropDownList1=selectedItem&Button1=Submit

It’s an &-separated string of name/value pairs. These values are loaded into an internal-use collection. The page processor attempts to find a match between names in the posted collection and ID of controls in the page. Whenever a match is found, the processor checks whether the server control implements the IPostBackDataHandler interface. If it does, the methods of the interface are invoked to give the control a chance to refresh its state in light of the posted data. In particular, the page processor invokes the LoadPostData method on the interface. If the method returns true—that is, the state has been updated—the control is added to a separate collection to receive further attention later.

If a posted name doesn’t match any server controls, it is left over and temporarily parked in a separate collection, ready for a second try later.

Note

As mentioned, during the processing of posted data, posted names are matched against the ID of controls in the page. Which ID? Is it the ClientID property, or rather, is it the UniqueID property? Posted names are matched against the unique ID of page controls. Client IDs are irrelevant in this instance because they are not posted back to the server.

The PreLoad Event

The PreLoad event merely indicates that the page has terminated the system-level initialization phase and is going to enter the phase that gives user code in the page a chance to further configure the page for execution and rendering. This event is raised only for pages.

The Load Event

The Load event is raised for the page first and then recursively for all child controls. At this time, controls in the page tree are created and their state fully reflects both the previous state and any data posted from the client. The page is ready to execute any initialization code related to the logic and behavior of the page. At this time, access to control properties and view state is absolutely safe.

Handling Dynamically Created Controls

When all controls in the page have been given a chance to complete their initialization before display, the page processor makes a second try on posted values that haven’t been matched to existing controls. The behavior described earlier in the Processing Posted Data section is repeated on the name/value pairs that were left over previously. This apparently weird approach addresses a specific scenario—the use of dynamically created controls.

Imagine adding a control to the page tree dynamically—for example, in response to a certain user action. As mentioned, the page is rebuilt from scratch after each postback, so any information about the dynamically created control is lost. On the other hand, when the page’s form is submitted, the dynamic control there is filled with legal and valid information that is regularly posted. By design, there can’t be any server control to match the ID of the dynamic control the first time posted data is processed. However, the ASP.NET framework recognizes that some controls could be created in the Load event. For this reason, it makes sense to give it a second try to see whether a match is possible after the user code has run for a while.

If the dynamic control has been re-created in the Load event, a match is now possible and the control can refresh its state with posted data.

Handling the Postback

The postback mechanism is the heart of ASP.NET programming. It consists of posting form data to the same page using the view state to restore the call context—that is, the same state of controls existing when the posting page was last generated on the server.

After the page has been initialized and posted values have been taken into account, it’s about time that some server-side events occur. There are two main types of events. The first type of event signals that certain controls