ASP.NET introduces an event-handling method similar to client applications like a WPF or WF application. The main different between the classic event-handling and ASP.NET’s event-handling procedure is that in ASP.NET, a server is involved. Events are triggered in the browser, which needs to communicate them to the server. Sometimes you got to remember yourself to this fact when dealing with events.
ASP.NET server controls have a large number of predefined events, and event handling code uses the traditional .NET signature, an object, which is the sender of the event, and any event-specific information wrapped in an EventArgs class.
To understand how and when you can handle events, let’s take a look at the page events of ASP.NET:
|PreInit||This event fires first when a page is being requested. You should add dynamically created controls here, or set the master page/style them programmatically here.|
|Init||Occurs when the page is initialized. The controls are initialized, but their properties don’t.|
|Load||The properties of the page are loaded back from the ViewState (or built up, if not a postback).|
|Validate||Not an event you can respond, validation of controls occurs here.|
|Event Handling||The events of the controls on the page are fired.|
|Render||Page render is running.|
To help you memorize this pattern, use SILVER as your keyword.
It is important to note that the controls on a page are going through the exact same life-cycle as the page itself. For example, first the page’s init event occurs, then the page calls the appropriate handler of each controls’ init event. If you added a control dynamically, there will be a little delay, but the control’s life-cycle will catch up with the page later.
In C# the page life-cycle events are wired up automatically, with a predefined naming syntax (such as Page_Load). In larger applications, this can cause a performance overhead, since the runtime will constantly look for these event handlers in your code. If you’re developing an application which will has to deal with large traffic, or just want to use custom naming syntax for your page event handlers, you should set the AutoEventWireup property in the @Page directive to false. Then you can use custom names for page events. You can specify them at the form tag, such as:
<form runat=”server” id=”form1” onload=”LoadMe”>
Or wire up an event in code:
Page.Init += new EventHandler(InitMe);
An ASP.NET application has application levels as well. You can sign up to these events in the Global.asax file. The main application events are:
|Application_Start||Occurs when IIS starts your application. Typically the result of the first user request.|
|Application_End||Occurs when IIS unloads your application, due to timeout, or application pool recycling, or as the result of configuration modification.|
|Session_Start||Occurs when a new session is initialized. Typically for a new user.|
|Session_End||Occurs when the user times out, or ends a session. Only when sessionState is set to InProc.|
|Application_Error||Occurs when unhandled exceptions occur in your application. To get the exception, use:
Exception ex = Server.GetLastError();
Control Page Flow
Your ASP.NET pages have a property called IsPostBack. You can use this value to determine whether the page has been built for the first time, or is the result of a postback to the server. This can be useful if you are dealing with resource-intensive methods.
You can navigate to another page programmatically by two methods, namely Response.Redirect and Server.Transfer.
You use Response.Redirect to simply redirect to a page. This method simply instructs the browser to request another page, inside or outside of your application.
The Server.Transfer method is a little bit more complex. It instructs the server to set its focus on another page of the same application. So you cannot use it to navigate to external sites. Also, Server.Transfer is able to preserve all form and query string parameters, which you will be able to inspect using the Request.Form(“controlName”) method.
You can also use Cross-Page Posting to navigate to another page. This can be achieved by a button (or any other control with a PostBackUrl property). Simply set this property to the target. Then, on the target page you can access to the source page’s controls and public variables by using the PreviousPage class. To find a value, use the following syntax:
if(PreviousPage != null)
TextBox tb = (PreviousPage.FindControl(“MyTextBox”) as TextBox;
myLabel.Text = tb.Text;
You should check the PreviousPage for null value before you try to get its values.