Examining How Event Handlers Work
|
As mentioned in Chapter 2, your programs revolve around the concept of events and event handlers. You created a handler for the button s Click event in the Programming the Button section earlier in this chapter. If you want something to happen in response to a Click event, you write some code to handle the event. Naturally, this code is called an event handler. Let s look at your event handler again:
Sub Button1_Click(sender As Object, e As Event Args Label1.Text = TextBox1.Text End Sub
The word Sub indicates to Microsoft Visual Basic .NET that the little program you ve created is a subroutine, or a smaller program within a larger program. (The larger program is the page itself.) The subroutine runs from the word Sub through the words End Sub.
The text Button1_Click tells ASP.NET that you re writing a Click event handler for the control called Button1. Your pages can have all sorts of button controls, and each one can have a different event handler for its Click event, depending on what tasks you want performed when users click that button.
Different controls have different events for which you can write a handler. Buttons obviously have a Click event. Drop-down lists and list boxes have a selection event called SelectedIndexChanged that s raised when the user chooses an item from the list. Other controls have yet other events, and more sophisticated controls can have a dozen or more events.
Not all events are raised directly by user actions such as clicking a button or selecting an item from the list. For example, the page itself has a Load event that is raised when the page starts. We ll use Page_Load a lot.
When the event handler runs, ASP.NET passes information into it using the two arguments you see in parentheses, sender and e. (The e stands for event, I guess.) These two arguments are passed to all event handlers. (Be aware that if you create other subroutines that are not event handlers, they will have different arguments or perhaps have none at all.) The arguments can tell you additional information about the event besides, for example, just that it was a Click event. The sender argument has information about which control raised the event. The e argument can contain a variety of information, depending on the exact event. For a Click event, the e argument doesn t actually contain any useful information. Other events pass more information into the handler, such as details about which item in a list was selected.
 |
If you re a Visual Basic programmer, you will be very familiar with events. By design, the ASP.NET team wanted to implement a Visual Basic like model for event handling in Web Forms pages. However, the events in the new model aren t events in the sense that you re used to. Consider: a button in a Web Forms page is displayed in the browser on a user s computer. The user clicks the button on his or her own computer, but the corresponding Click event handler runs on a Web server computer that could be halfway around the world. It s a little strange, but ASP.NET magic is at work here. Under the covers, when a user clicks the button, the browser posts the page to the Web server with a string of data containing the values of controls on the page. ASP.NET reads the string and, based on what it finds there, runs code that looks like the event handlers you re used to. For the most part, you can use this metaphoric event model without much thought. But a number of issues arise out of the difference between traditional Windows-based events and the events that ASP.NET has constructed here. I ll point out some of these issues as we go, but be prepared for the occasional moment of confusion.
One more note: you ll be surprised to see how few events Web Forms controls have compared to the many events you re used to working with. This is due to the fact that the user and Web server are (or can be) on separate computers. Remember that every event for a Web control has to be handled on the server, which requires a round trip. The number of events for which it s practical to cause a round trip is, of course, quite limited.
|
|
If you ve ever created client script (for example, JavaScript or Microsoft Visual Basic Scripting Edition [VBScript]) for a Web page, you might be wondering how the button s Click event relates to the events you can program in the browser. The short answer is that the Click event we re working with here is actually an HTML form submit. The buttons you put on a Web Forms page are all configured to submit the page on click and, specifically, to submit the page to itself. When the submit is processed on the server by ASP.NET, ASP.NET converts the submission into an ASP.NET Click event.
The server-based programming we re doing here has almost nothing to do with the kind of client (browser) programming you can do with JavaScript or VBScript. In JavaScript programming, for example, you can respond to all sorts of events such as onmouseover, onblur, and so on. These events aren t exposed in ASP.NET programming because ASP.NET code runs only when the page is posted. For example, it would be hugely inefficient to post the page every time the user waves the mouse over a control. The good news is that using ASP.NET doesn t prevent you from using client-side script, so you can still program mouse-over effects and other events. However, you won t program such events in ASP.NET.
|
|
