7.6. Understanding the Page Event Life Cycle

Events are raised on the client side as the user interacts with the form. The event information is captured and either immediately transmitted to the Web server through an HTTP post or cached until a post is triggered. The actual event handling is carried out on the server. When done, the modified page is then rendered into HTML and streamed back to the client for display.

Because event handling requires a round-trip, events that occur frequently and that can be raised without the user even being aware, such as a mouse-over, are not supported. In fact, by default only click events cause the page to be posted back to the server. Change events, such as the filling in of a text box or the selection of a radio button, are captured but do not cause an immediate post. When a post does occur, these captured events are raised and processed before the event that triggered the post; the order of processing the pending events, however, is undefined. (To force the immediate posting of a change event, we can set the control's AutoPostBack property to true.)

A Web Forms page goes through a complete life cycle on the Web server following the initial page request and with each subsequent round-trip. In the life cycle's first phase, the compiled page is retrieved and loaded. The page and control view states are initialized (or restored if this represents a post back). A Load event is then raised and the associated callback is invoked.

In our application we need to populate a DataGrid control with the NorthWind employee records from our SQL database before displaying the page to the user. The Page_Load() event handler is where this kind of one-time page initialization is placed.

Here are the three steps in binding data to a Web control. First, we populate a DataSet object with the SQL database records. We then set the DataGrid object's DataSource property to the first table within the data set. Under Windows Forms, this would be sufficient for the successful display of the data grid. Under Web Forms we must then explicitly invoke the DataBind() method of the DataGrid object; otherwise neither the data nor the grid displays.^[6]

^[6] This example captures something of the nature of learning a new technology. If we do not invoke DataBind(), no warning is generated. Nothing seems wrong, but nothing is working. In this case, what you don't know can drive you up the wall.

protected void Page_Load(object sender, EventArgs e)
{
   DateTime theDate = DateTime.Now;
   Label3.Text = theDate.ToLongDateString() + " " +
                 theDate.ToLongTimeString();

   string cs = "server=localhost;uid=sa;pwd=;database=northwind";
   SqlConnection conn = new SqlConnection( cs );

   string cmd =
      "select LastName,FirstName,Title,HomePhone from Employees";

   SqlCommand scmd = new SqlCommand( cmd, conn );
   DataSet ds = new DataSet();

   SqlDataAdapter sda = new SqlDataAdapter();
   sda.SelectCommand = scmd;

   sda.Fill( ds, "Employees" );
   conn.Close();

   // OK: fill the DataGrid
   DataGrid1.DataSource = ds.Tables[0].DefaultView;

   // now bind the data ...
   DataGrid1.DataBind();
}

This implementation is almost correct. The problem is that Page_Load() is invoked with each post back. Because the database does not change between round-trips, there is no benefit in executing the database code more than once, although we would like to update the DateTime object with each round-trip.

We need to execute code conditionally, on the basis of whether the Page_Load() invocation is in response to a page request or a subsequent post back. We do this through a test of the IsPostBack property of the page. When it evaluates to false, Page_Load() is handling the initial page request:

protected void Page_Load(object sender, EventArgs e)
{
   // always evaluate this
   DateTime theDate = DateTime.Now;
   Label3.Text = theDate.ToLongDateString() + " " +
                 theDate.ToLongTimeString();
   // evaluate this once at the initial page request
   if ( ! IsPostBack )
   {
      // the database code goes here
   }
}

At the other end of the life cycle the page is disposed of following the HTML rendering of its content back to the client. An Unload event is raised. We can add our code to the event handler to perform any necessary cleanup.