Visual Basic and client-side JavaScript programmers will certainly be familiar with the concept of events and event-driven programming. Most ASP programmers will probably have come across the event-driven programming paradigm as well. It is very important that you understand the event-driven programming model, as all ASP.NET applications revolve around this principle.
For the uninitiated, event-driven programming revolves around building code that is executed according to the actions the user performs (for our purposes, at least— event-driven programming does actually encompass a significant amount more than this). The programming language and infrastructure performs all the plumbing of capturing user actions and providing the appropriate conditions, and most of what the programmer is required to do is write the code that needs to be executed when a particular event occurs. An example of an event is the clicking of a button.
Event handlers are the subroutines that are called when an event occurs. Visual Studio can generate blank event-handler blocks and link them (hook them up) to the appropriate objects. To get Visual Studio to do this, double-click the Button Web Control on the form. This will hook up a click event for the button. Visual Studio will also automatically switch to the code (not HTML) view, which displays all the serverside code for the Web Form.
This marker indicates there is code that is not being shown. Clicking the plus sign (+) will reveal the code. This functionality operates very similarly to treeview controls, but it contains code rather than nodes. Thus, after expanding the code by clicking the plus sign, the sign will change to a minus sign (–), and clicking the minus sign will hide the code again. Notice that all Subs also have this functionality, which at first may seem fairly pointless, but is actually very useful when dealing with large blocks of code. For Visual Basic developers, this replaces the Sub View mode, where only one subroutine could be viewed at a time.
Dissecting the Pregenerated Code
With the exception of the control definitions and Button1 click event handler, all Web Forms created using Visual Studio will by default have the server-side code.
The Public Class WebForm1 statement defines the start of a class for the Web Form. Note the End Class statement at the end of the code.
The Inherits statement is used to instruct the compiler to inherit all the inheritable members (properties, methods, and events) of the System.Web.UI.Page class.
For those unfamiliar with inheritance, this essentially means that the WebForm1 class contains everything a Page class does, and then adds its own members. This is important, as the Page class contains many members that are critical to interacting with both the server and the client, and forms the base for all ASP.NET Web Forms.
The next two statements (repeated in the code that follows) are the control declarations for the two Web Controls that were added to the form. The reason these declarations need to be included in the server-side code when they already exist in the UI code is so that they are accessible from within the class and can have event handlers attached to them.
Next is the code region. Code regions are used for grouping together related, adjacent pieces of code. In Visual Studio this results in a collapsible region being created.
The private InitializeComponent sub is used for any component initialization that needs to occur. This does not currently contain any code, but this event handler is normally used when nonvisible controls are added to the page.
The Page_Init Sub is an event handler for the Page’s Init event. Event handlers generally take the form of ObjectName_EventName. In this event handler, the InitializeComponent routine is called. All code that may need to be included in this event handler should follow that call.
The Page Init event is triggered when a page is loaded, followed by the Load event. The Page_Load method is the event following the Init event.
Finally, the Button1_Click event handler is what was created when the Button on the form was double-clicked. This method is called when Button1 is clicked.
For the uninitiated, event-driven programming revolves around building code that is executed according to the actions the user performs (for our purposes, at least— event-driven programming does actually encompass a significant amount more than this). The programming language and infrastructure performs all the plumbing of capturing user actions and providing the appropriate conditions, and most of what the programmer is required to do is write the code that needs to be executed when a particular event occurs. An example of an event is the clicking of a button.
Event handlers are the subroutines that are called when an event occurs. Visual Studio can generate blank event-handler blocks and link them (hook them up) to the appropriate objects. To get Visual Studio to do this, double-click the Button Web Control on the form. This will hook up a click event for the button. Visual Studio will also automatically switch to the code (not HTML) view, which displays all the serverside code for the Web Form.
This marker indicates there is code that is not being shown. Clicking the plus sign (+) will reveal the code. This functionality operates very similarly to treeview controls, but it contains code rather than nodes. Thus, after expanding the code by clicking the plus sign, the sign will change to a minus sign (–), and clicking the minus sign will hide the code again. Notice that all Subs also have this functionality, which at first may seem fairly pointless, but is actually very useful when dealing with large blocks of code. For Visual Basic developers, this replaces the Sub View mode, where only one subroutine could be viewed at a time.
Dissecting the Pregenerated Code
With the exception of the control definitions and Button1 click event handler, all Web Forms created using Visual Studio will by default have the server-side code.
The Public Class WebForm1 statement defines the start of a class for the Web Form. Note the End Class statement at the end of the code.
The Inherits statement is used to instruct the compiler to inherit all the inheritable members (properties, methods, and events) of the System.Web.UI.Page class.
For those unfamiliar with inheritance, this essentially means that the WebForm1 class contains everything a Page class does, and then adds its own members. This is important, as the Page class contains many members that are critical to interacting with both the server and the client, and forms the base for all ASP.NET Web Forms.
The next two statements (repeated in the code that follows) are the control declarations for the two Web Controls that were added to the form. The reason these declarations need to be included in the server-side code when they already exist in the UI code is so that they are accessible from within the class and can have event handlers attached to them.
Protected WithEvents Button1 As System.Web.UI.WebControls.Button<br>
Protected WithEvents Label1 As System.Web.UI.WebControls.Label
Next is the code region. Code regions are used for grouping together related, adjacent pieces of code. In Visual Studio this results in a collapsible region being created.
The private InitializeComponent sub is used for any component initialization that needs to occur. This does not currently contain any code, but this event handler is normally used when nonvisible controls are added to the page.
The Page_Init Sub is an event handler for the Page’s Init event. Event handlers generally take the form of ObjectName_EventName. In this event handler, the InitializeComponent routine is called. All code that may need to be included in this event handler should follow that call.
The Page Init event is triggered when a page is loaded, followed by the Load event. The Page_Load method is the event following the Init event.
Finally, the Button1_Click event handler is what was created when the Button on the form was double-clicked. This method is called when Button1 is clicked.
No comments:
Post a Comment