Section 9.5. Understanding Event Order

9.5. 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 burstsbeginning 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
OnInit event	Create the web part.
LoadViewState method	Override the web part's base class behavior when reading control properties from the web part's ViewState object.
CreateChildControls method	Add web controls to the Controls collection.
Onload event	Initialize resources used by the web part.
Cached child control events	Process cached events from child controls, such as TextChanged or SelectedIndexChanged .
Postback child control event	Process the event that caused the postback, for example the button Click event.
OnPreRender event	Set child control properties and complete any processing before rendering the part.
SaveViewState method	Override the web part's base class behavior when saving control properties to the web part's ViewState object.
RenderWebPart method	Draw the web part as HTML.
Dispose method	Release resources used by the web part.
OnUnload event	Finalize the release of resources.

Web parts have many more events and methods than those in Table 9-2, but the ones there are critical to understanding how to code web parts and avoid unexpected results. That's also why I combined events and methods in the same tableit's important to know that the CreateChildControls method is called before the OnPreRender event occurs, for example.

The other thing that's important about the information in Table 9-2 is that cached events occur before the event that caused the postback. Cached events are server-side events that occur on a child control, but that don't cause a postback. SharePoint determines what cached events occurred by checking the web part's ViewState ; then SharePoint raises those events after the web part loads.

See the EventOrder.aspx sample to test the sequence of events on a web part. That sample records the order of events and displays the results after a postback as shown in Figure 9-10. The code for the EventOrder simply appends a string to display as shown here:

 Protected Overrides Sub OnInit(ByVal e As System.EventArgs)          _msg &= "OnInit event<br>"      End Sub 

animal 9-10. Testing the order of events and method calls

 Protected Overrides Sub LoadViewState(ByVal savedState As Object)          _msg &= "LoadViewState method<br>"          ' Delegate back to base class.          MyBase.LoadViewState(savedState)      End Sub ...