Understanding Event Order
From an 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 responds as events occur. Web part code runs only 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 textbox, 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 9-2.
Table 9-2. 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 ... |
Get Essential SharePoint now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.