Adding Code to the Event Handler (PART-14)

Adding code to the event handler is, well, exactly as you would expect it to be. Place the cursor in the space between Protected Sub Button1_Click(…) and End Sub and type the appropriate code in. For

now, all the code will do is change the text of the label (Label1) to, you guessed it, "Hello world!". Type in the following code, and pause after you type the period:


Label1.Text = "Hello world!"

Pausing after typing the period should result in a list box being displayed, as shown in Figure.

The period in VB .NET is the member selection operator. Visual Studio, realizing that a member of the Label1 object is about to be referenced, preemptively displays a list of choices of all the members of

Label1 that can currently be accessed. If you type T, the list scrolls down to all the choices beginning with T. This feature is particularly useful when you know what a method name starts with but are not

quite sure how to spell it. It prevents the trouble of loading help and looking up the member in question or, if the object is a custom-built class, opening the class’ code to check. Complete the code as

shown previously. This code assigns the string "Hello world!" to the Text property of Label1.

Running the Application

Run the application either by using the menu command Debug-Start or by pressing F5. The IDE will change form slightly and go into debug mode. Basically, this means that the Form Designer and several other design-time windows are hidden if they were visible, and debug tool windows may be opened.

Internet Explorer should appear, showing a page similar to that shown in Figure.

After you click Button1, there will be a slight pause, and the text Label will be changed to "Hello world!". Before you close Internet Explorer, note the URL of the page. It should be in the form of

http://localhost/WebApplication1/WebForm1.aspx. Closing Internet Explorer will return Visual Studio to Design mode.

Behind the Scenes

For what is a very small and trivial example, there is actually a large amount happening behind the scenes, as it were, both in terms of creating the application and running it.

Application Creation

Every time a new Web application is created in Visual Studio, several operations are performed. First, a new directory is created in the IIS default site’s physical root. By default the physical root is

c:\inetpub\wwwroot. This directory is of the same name as the name chosen for the Web application in the New Project dialog box. Second, several files are created that form the basis of the application.

These include such files as global.asax, web.config, styles.css, as well as one Web Form file set with the same name as the application (each Web Form consists of two files—one aspx file containing the

UI code, and one aspx.vb file containing the server-side code). Third, Visual Studio solution and Visual Studio project files are created and placed in the appropriate directories. Finally, a virtual directory is set up in IIS.

NOTE A virtual directory in IIS allows directories other than those in the physical Web root to be accessed. For example, if the physical Web root was c:\inetpub\wwwroot, and c:\somesite needed

to be accessed, and that folder could not be moved, you could set up a virtual directory so that users who visited http://machinename/virtualdirname would actually receive content from c:\somesite.

However, Visual Studio sets up a virtual directory for each application for a different reason—in order for events from IIS to be handled by ASP.NET on a perapplication basis, the application must be in a virtual directory.

Application Execution

ASP.NET is a compiled environment, but it alleviates one of the key annoyances of other compiled environments. The developer never has to compile the files him- or herself—all compilation is performed

automatically by ASP.NET. Additionally, when a compilation occurs, only the files that have been changed need to be compiled, not the entire application. The following list details the compilation procedure for a totally new ASP.NET application:

• An aspx file in http://elite/asp.net is hit (someone visited it).
• ASP.NET goes through the c:\inetpub\wwwroot\someapp directory (assuming c:\inetpub\wwwroot is the physical root path) and compiles all the ASP.NET files in the directory.
• The originally requested file is served up to the user.
• All subsequent hits to ASP.NET files in that directory are served immediately (no need for recompilation).

Then assume that somefile.aspx is modified. Here is the next hypothetical sequence of events:

• somefile.aspx is hit.
• ASP.NET realizes that the files in the directory have already been compiled and this is not a first hit, so it only recompiles somefile.aspx.
• somefile.aspx is served up to the user.
• All subsequent hits to somefile.aspx are served immediately.

In summary, ASP.NET is intelligent in its compilation policy and performs all compilations without any user intervention required, thus combining the speed of compiled environments with the flexibility and ease of use of interpreted environments.