Professional VB 2005 with .NET 3.0 (Programmer to Programmer)

In the past, one of the difficulties in working with classic ASP was that you were completely in charge of the entire HTML output from the browser by virtue of the server-side code you wrote. Although this might seem ideal, it created a problem because each browser interpreted the HTML given to it in a slightly different manner.

The two main browsers at the time were Internet Explorer and Netscape Navigator. This meant that not only did developers have to be cognizant of the browser type to which they were outputting HTML, they also had to take into account which versions of those particular browsers might be making a request to their application. Some developers resolved the issue by creating two separate applications. When an end user made an initial request to the application, the code made a browser check to see what browser type made the request. Then, the ASP page redirected the request: down one path for an IE user or down another path for a Netscape user.

Because requests came from so many different versions of the same browser, developers often designed for the lowest possible version that might be used to visit the site. Everyone loses when the lowest common denominator is used as the target. This technique ensures that the page is rendered properly in most browsers making a request, but it also forces developers to dumb down their applications. If applications are built for the lowest common denominator, developers can’t take advantage of some of the more advanced features offered by newer browser versions.

ASP.NET server controls overcome these obstacles. When using the server controls provided by ASP.NET, you are not specifying the HTML to be output from your server-side code. Rather, you are specifying the functionality you want to see in the browser, letting the ASP.NET determine the output to be sent to the browser.

When a request comes in, ASP.NET examines the request to see which browser type is making the request, as well as the version of the browser, and then it produces HTML output specific to that browser. This process is accomplished by processing a User Agent header retrieved from the HTTP Request to sniff the browser. This means that you can now build for the best browsers out there without worrying about whether features will work in the different browsers making requests to your applications. Because of the previously described capabilities, these controls are often referred to as smart controls.

Types of Server Controls

ASP.NET provides two distinct types of server controls - HTML server controls and Web server controls. Each type of control is quite different; and as you work with ASP.NET, you will see that much of the focus is on the Web server controls. This doesn’t mean that HTML server controls have no value. They do provide you with many capabilities - some that Web server controls do not.

You might be asking yourself which is the better control type to use. It really depends on what you are trying to achieve. HTML server controls map to specific HTML elements. You can place an HtmlTable server control on your ASP.NET page that works dynamically with a <table> element. On the other hand, Web server controls map to specific functionality that you want on your ASP.NET pages. This means an <asp:Panel> control might use a <table> or an <IFrame> element - it really depends on the capability of the requesting browser.

The following table summarizes some advice on when to use HTML server controls and when to use Web server controls:

Of course, some developers like to separate certain controls from the rest and place them in their own categories. For instance, you may see references to the following types of controls:

• List controls: Enable data to be bound to them for display purposes of some kind

• Rich controls: Controls, such as the Calendar control, that display richer content and capabilities than other controls

• Validation controls: Controls that interact with other form controls to validate the data that they contain

• Mobile controls: Specific to output to devices such as mobile phones, PDAs, and more

• User controls: Not really controls, but page templates that you can work with as you would a control on your ASP.NET page

• Custom controls: Controls that you build yourself and use in the same manner as the supplied ASP.NET server controls that come with the default install of ASP.NET 2.0

When you are deciding between HTML server controls and Web server controls, remember that no hard-and-fast rules exist about which type to use. You might find yourself working with one control type more than another, but certain features are available in one control type that might not be available in the other. If you are trying to accomplish a specific task and don’t see a solution with the control type you are using, another control type may very well hold the answer. Keep in mind that you can mix and match these control types. Nothing prevents you from using both HTML server controls and Web server controls on the same page or within the same application.

Building with Server Controls

You have a couple of ways to use server controls to construct your ASP.NET pages. You can use tools that are specifically designed to work with ASP.NET 2.0 that enable you to visually drag and drop controls onto a design surface and manipulate the behavior of the control, or you can work with server controls directly through code input.

Working with Server Controls on a Design Surface

Visual Studio 2005 enables you to visually create an ASP.NET page by dragging and dropping visual controls onto a design surface. You can get to this visual design option by clicking the Design tab at the bottom of the IDE when viewing your ASP.NET page. In this view, you also can place the cursor on the page in the location where you want the control to appear and then double-click the control you want in the Toolbox window of Visual Studio. Unlike previous versions of Visual Studio, Visual Studio 2005 does a really good job of not touching your code when switching between the Design and Source tabs.

In the Design view of your page, you can highlight a control and the properties for the control appear in the Properties window. For example, Figure 19-13 shows a Button control selected, with its properties displayed in the Properties window on the right.

Figure 19-13

Changing the properties in the window changes the appearance or behavior of the highlighted control. Because all controls inherit from a specific base class (WebControl), you can highlight multiple controls at the same time and change the base properties of all the controls at once by holding down the Ctrl key as you make your control selections.

Coding Server Controls

You also can work from the code page directly. Because many developers prefer this, it is the default when you first create your ASP.NET page. Hand-coding your own ASP.NET pages may seem to be a slower approach than simply dragging and dropping controls onto a design surface, but it isn’t as slow as you might think. You get plenty of assistance in coding your applications from Visual Studio 2005. As you start typing in Visual Studio, the IntelliSense features kick in and help you with code autocompletion. Figure 19-14, for example, shows an IntelliSense drop-down list of possible code completion statements that appeared as the code was typed.

Figure 19-14

The IntelliSense focus is on the most commonly used attribute or statement for the control or piece of code that you are working with. Using IntelliSense effectively as you work is a great way to code with speed.

As with Design view, the Source view of your page enables you to drag and drop controls from the Toolbox onto the code page itself. For example, dragging and dropping a TextBox control onto the code page produces the same results as dropping it on the design page:

<asp:TextBox Runat="server"></asp:TextBox>

You can also highlight a control in Source view or simply place your cursor in the code statement of the control, and the Properties window displays the properties of the control. You can apply properties directly in the Properties window of Visual Studio, and these properties are dynamically added to the code of your control.

Working with Server Control Events

ASP.NET uses more of a traditional Visual Basic event model than classic ASP. Instead of working with interpreted code, you are actually coding an event-based structure for your pages. Classic ASP used an interpreted model: When the server processed the Web page, the code of the page was interpreted line by line in a linear fashion whereby the only “event” implied was the page loading. This meant that occurrences you wanted to initiated early in the process were placed at the top of the page.

Today, ASP.NET uses an event-driven model. Items or coding tasks are initiated only when a particular event occurs. A common event in the ASP.NET programming model is Page_Load, shown here:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) ' Code actions here End Sub

Not only can you work with the overall page - as well as its properties and methods at particular moments in time through page events - you can also work with the server controls contained on the page through particular control events. For example, one common event for a button on a form is Button_Click, illustrated here:

Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) ' Code actions here End Sub

The event shown here is fired only when the end user actually clicks the button on the form that has an OnClick attribute value of Button1_Click. Therefore, not only does the event handler exist in the server-side code of the ASP.NET page, but that handler is also hooked up using the OnClick property of the server control in the associated ASP.NET page markup, as illustrated in the following code:

<asp:Button Runat="server" Text="Button" OnClick="Button1_Click" />

How do you fire these events for server controls? You have a couple of ways to go about it. The first way is to pull up your ASP.NET page in Design view and double-click the control for which you want to create a server-side event. For instance, double-clicking a Button server control in Design view creates the structure of the Button1_Click event within your server-side code, whether the code is in a code-behind file or inline. This creates a stub handler for that server control’s most popular event.

That said, be aware that a considerable number of additional events are available to the Button control that you cannot access by double-clicking the control. To access them, pull up the page that contains the server-side code, select the control from the first drop-down list at the top of the IDE, and then choose the particular event you want for that control in the second drop-down list. Figure 19-15 shows the event drop-down list displayed. You might, for example, want to work with the Button control’s PreRender event, rather than its Click event. The handler for the event you choose is placed in your server-side code.

Figure 19-15

The second way is to create server-side events for your server controls from the Properties window of Visual Studio. This works only from Design view of the page. In Design view, highlight the server control that you want to work with. The properties for the control will appear in the Properties window, along with an icon menu. One of the icons, the Events icon, is represented by a lightning bolt within the IDE.

Clicking the Events icon pulls up a list of events available for the control. Simply double-click one of the events to get that event structure created in your server-side code. After you have an event structure in place, you can program specific actions you want to occur when the event is fired.