Understanding Event Order
From event perspective, web part programming is very different from Windows Forms programming. In Windows Forms applications, code runs as long as the form is displayed, and code as events occur. Web part code runs only in short bursts—beginning when the request is received by the server and ending shortly after the response is returned to the client browser.
The performance difference between the server and client Sum controls illustrates a basic principle of web part design: avoid unnecessary postbacks. The button web control and Submit button trigger postback events by default, but you can also set the AutoPostback property on text box, list, and checkbox controls to cause postbacks. When a postback event occurs, the browser sends the current state of the page back to the server, which then processes web part events and overridden methods in the order shown in Table 11-4.
Table 11-4. Order of major server events/methods in a web part
Event/method | Use to |
|---|---|
| Create the web part. |
| Override the web part's base class behavior when reading control properties from the web part's |
| Add web controls to the Controls collection. |
| Initialize resources used by the web part. |
Cached child control events | Process cached events from child controls, such as |
Postback child control event | Process the event that caused the postback—for example, the button |