Postback events are your chance to make something happen when a user interacts with the form. A postback occurs when a button is clicked or in cases where some other control's state is changed and forced to postback automatically (a DropDownList's AutoPostBack property, for example, might be set to true, forcing a postback when the user changes the selection in the control).
Event handler methods all follow the same signature. They have no return value (void in C#) and require two parameters. The first is an object parameter, generally called sender, to provide a reference back to the control that raised the event. The second parameter is of type EventArgs, which is a collection of arguments. Not all controls return arguments, but the method still must include them.
The reason for this method signature is that event handlers are actually calling a delegate called System.EventHandler. We skipped over delegates and events in Chapter 2, "Classes: The Code Behind the Objects," because a lot of people have a really hard time understanding them at first, and we were already throwing a lot of information at you in that chapter. Delegates frequently get lengthy chapters in C# and VB.NET books. Let's just keep it simple for now and say that delegates define a method signature so that some piece of code (the ASP.NET plumbing) can call a method with a known return value and parameters (your event handler).Table 7.1, you'll notice that there's a place in the Page column for postback event handlers to fire. Notice its position compared to the page's Load and PreRender events. This might give you a hint on how best to handle the display of data on your form. For example, it wouldn't make sense to bind data to a DataGrid if that data was somehow changed by your postback event handler. The data returned to the user would end up being stale! Instead, you could bind this data in the Page_PreRender event, ensuring that queries to your database receive the current data.