For the most part, HTML server controls use the same attributes as their ordinary HTML counterparts. The exceptions are:

There are several ways your code can inspect and modify other, more ordinary attributes of HTML server controls:

Using <span> tags as generic controls is a handy way of displaying variable text on a Web page without resorting to code render blocks. To display an error message, for example, you could put the following tag where you want the message to appear:

<span id="spnErrMsg" runat"server" />

Then, in the Page_Load subroutine or some other event handler, you could code statements like the following:

spnErrMsg.InnerText = "Sorry, can't deal with quantity of -1."

Some HTML server controls implement selected attributes as full-blown object properties. The HtmlImage control, for example, supports the src and alt attributes as properties. If your page contained the following HtmlImage control:

<img src="mypetmoose.jpg" id="imgPetPic" runat="server" />

and you wanted to write code that made this tag display the picture yourturtle.jpg, you could code

imgPetPic.src = "yourturtle.jpg"

If you wanted your code to specify alternate text of Pets are great, you could code

imgPetPic.alt = "Pets are great"

even if you didn’t code an alt attribute in the original tag.

If an HTML server control supports an attribute as a fully implemented property, it’s generally better to use the property than to use the Attributes collection, the Styles collection, or the InnerHTML or InnerText properties. In case of doubt, you can either

The ability to modify page elements this way from code is a powerful facility and, unlike classic ASP, you don’t have to garbage up your HTML by putting <% and %> tags in odd places.

To look up the syntax of a specific HTML server control, search the MSDN Web site (msdn.microsoft.com/library) for the terms ASP.NET Syntax and HTML Server Controls.

ASP.NET pages can still receive form field values the way classic ASP pages have always done. The following statement retrieves the value of a form field named txtEntry and submitted with the POST method:

strEntry = Request.Form("txtEntry")

Likewise, the following expression retrieves the value of a similar field submitted with the GET method:

strEntry = Request.ServerVariables("txtEntry")

Despite the fact that expressions like these still work, it’s not common to find them in ASP.NET pages because you can only receive values this way—you can’t send them. ASP.NET form fields have properties that can both receive and send form field values, and it’s these properties that ASP.NET programmers most often use. The property names for each type of form field appear in the Form Field Value column of the HTML Server Controls table in Using Assignment Operators.

The following statement, for example, retrieves the value of a hypothetical text box named txtEntry:

strEntry = txtEntry.Value

The following statement sets the value of the same form field:

txtEntry.Value = "Please enter some data here."

When ASP.NET renders a Web page, it automatically sets the value of each form element to the corresponding server control’s property value, which means that in the text box the Web visitor would see the words "Please enter some data here."

Keep in mind that server controls identify form fields differently than the Request.Form and Request.QueryString collections:

You can make both of these names the same in your code, but doing so is seldom necessary. In most cases, you can skip coding a name= attribute completely. ASP.NET will generate its own browser-side name for the field.

There is, however, one case where you must code both name= and id= attributes. For radio buttons, you must assign the same name= identity—but a different id= identity—to each button in the same group. (A group, in this sense, means a group of radio buttons where selecting one button deselects all others.) Here’s an example:

<input type="radio" runat="server"
       name="radSize" id="radSmall" value="Small" />
<input type="radio" runat="server"
       name="radSize" id="radMedium" value="Medium" />
<input type="radio" runat="server"
       name="radSize" id="radLarge" value="Large" />

Because all three buttons have the same name= attribute—radSize—selecting one—whether in the browser or in code—will deselect the others. The following statement, for example, will select the Large button and deselect the others:

radLarge.checked = True

From an ASP.NET standpoint, the name= attribute is for grouping and the id= attribute is for testing or changing the state of an individual button.

Create a Web page that uses HTML server controls

The following procedure will create a simple Web Form consisting of one text box and one Submit button. At any given time, the form will display the last three strings of text submitted, as shown in the following graphic. If you’d rather look at the finished code than enter it yourself, open the last3.aspx page in the ch04 folder you installed from the companion CD.

1. Open a new empty Web page containing the usual structural tags. Apply any page-level formatting you want. For example, the sample results include the following statement, which links to a shared Cascading Style Sheet file named normal.css:

   <link rel="stylesheet" type="text/css" href="../normal.css">

2. Add the following declaration above the <html> tag:

   <%@ Page Language="VB" Explicit="True" Debug="True"%>

3. After the <body> tag, add a heading and then a paragraph that will display the current date and time. Your code should resemble the following:

   <h2>The Last Three Entries</h2>
   <p>As of: <span id="spnDate" runat="server"></span></p>

   The <span> tag has id and runat="server" attributes so that code elsewhere in the page can modify the text it displays.

   Note

   From this point forward, we’ll assume that you know that the blue code in the examples indicates new additions, and we won’t mention it again.

4. After the declaration you created in step 2—and before the <html> tag—add a code declaration block as shown here:

   <%@ Page Language="VB" Explicit="True" Debug="True"%>
   <script runat="server">
   </script>
   <html>

5. Inside the code declaration block, define a subroutine that runs whenever ASP.NET loads the page. This requires the code shown here:

   <script runat="server">
   Sub Page_Load (sender As Object, e As EventArgs)
   End Sub
   </script>

6. Inside the Page_Load subroutine, add a statement that loads the spnDate control from step 2 with the current date and time. Here is the new statement:

   Sub Page_Load (sender As Object, e As EventArgs)
     spnDate.InnerHTML = Now()
   End Sub

7. Add a Web Form to the body of the Web page. To do this, add the following tags after the code you entered in step 2 (and just before the </body> tag):

   <form runat="server">
   </form>

8. Add a text box to the form you defined in the previous step. Put this text box inside a paragraph so that line breaks occur before and after it. This requires the code shown here:

   <form runat="server">
   <p><input type="text" id="txtEntry" size="20" runat="server"
   /></p>
   </form>

9. Add a Submit button to the end of the paragraph you just created. In other words, put the code that appears in blue just before the closing </p> tag:

   <form runat="server">
   <p><input type="text" id="txtEntry" size="20" runat="server"
   />
   <input type="submit" value="Enter" runat="server" /></p>
   </form>

10. Add three more paragraphs to the form, placing all three below the paragraph that’s already present. Within each paragraph, code a <span> tag that’s ready to receive a value from code:

    <p><span id="spnEntry1" runat="server"></span></p>
    <p><span id="spnEntry2" runat="server"></span></p>
    <p><span id="spnEntry3" runat="server"></span></p>

11. Return to the code declaration block near the top of the page. Immediately after the statement you added in step 5, add an If statement that checks to see whether a PostBack has occurred. That is, add the code shown here:

    Sub Page_Load (sender As Object, e As EventArgs)
      spnDate.InnerHTML = Now()
      If Page.IsPostBack Then
      End If
    End Sub

12. Every time the visitor clicks the Submit button, some code needs to perform these steps in this order:

    1. Copy the second previous value to the third previous value.

    2. Copy the first previous value to the second previous value.

    3. Copy the text box value to the first previous value.

    Therefore, within the If statement you just created, add the code shown here:

    If Page.IsPostBack Then
      spnEntry3.InnerHTML = spnEntry2.InnerHTML
      spnEntry2.InnerHTML = spnEntry1.InnerHTML
      spnEntry1.InnerHTML = txtEntry.Value
    End If

13. Save the Web page in a folder that’s accessible through your Web server, giving it a file name of last3.aspx.

14. Load the last3.aspx page into your browser, taking care to specify an HTTP URL and not an ordinary file location.

15. Type a word into the text box and click Enter. The word should appear below the text box. Repeating this operation with a different word should display both words in order, and so forth. In addition, the time and possibly the date should change each time you click Enter.

The code for the complete Web page appears here:

<%@ Page Language="VB" Explicit = "True" Debug="True" %>
<script runat="server">
Sub Page_Load(sender As Object, e As EventArgs)
  spnDate.InnerHTML = Now()
  If Page.IsPostBack Then
    spnEntry3.InnerHTML = spnEntry2.InnerHTML
    spnEntry2.InnerHTML = spnEntry1.InnerHTML
    spnEntry1.InnerHTML = txtEntry.Value
  End If
End Sub
</script>
<html>
<head>
<title>New Page 1</title>
<link rel="stylesheet" type="text/css" href="../normal.css">
</head>
<body>
<h2>The Last Three Entries</h2>
<p>As of: <span id="spnDate" runat="server"></span></p>
<form runat="server">
  <p><input type="text" id="txtEntry" size="20" runat="server" />
  <input type="submit" value="Enter" runat="server" /></p>
  <p><span id="spnEntry1" runat="server"></span></p>
  <p><span id="spnEntry2" runat="server"></span></p>
  <p><span id="spnEntry3" runat="server"></span></p>
</form>
</body>
</html>

Tags vs. Tags vs. Tags

The terms HTML server control, Web server control, custom server control and user control can be confusing, especially because for many developers, anything Web-related is HTML-related. Here’s a breakdown that should clarify the use of these terms:

• HTML server controls follow the syntax of traditional HTML tags, except that they contain the runat="server" attribute. The following tag, for example, creates an HTML server control:

  <input type="submit" runat="server" id="bthSub" value="Submit"
         onServerClick="btnSub_Click" />

• Web server controls are unique to ASP.NET and have tag names that begin with asp:. The following tag creates a Web server control:

  <asp:Button runat="server" id="bthSub" Text="Submit"
         OnClick="btnSub_Click" />

• Custom server controls are controls you or a third party write and then compile into a DLL.

• User controls also consist of code that you or a third party write. Unlike custom server controls, however, user controls run from source code.

The following tag creates a hypothetical custom server or user control.

<webdbpgm:gizmo runat="server" id="gizFred" diameter="50" />

In all four cases, no matter how strange the server control’s tag appears, the code that goes to the browser is perfectly ordinary HTML. Code built into the server control receives specifications from the tag attributes or from server-side code and then writes whatever HTML it needs to accomplish the desired result.

This next procedure will create a simple Web Form that uses the DropDownList, TextBox, Calendar, and Literal Web server controls. It also illustrates a number of server-side subroutines that respond to events on the browser. The graphic shows the finished page:

If you’d rather look at the finished code than enter it yourself, open the calendar.aspx page in the ch04 folder you installed from the companion CD. Otherwise, proceed as follows:

Although you might admire the calendar.aspx page simply because of its good looks, the page would be even more impressive if the controls interacted properly. To make this happen, you must supply correct code in each of the event handler subroutines. To begin, open the calendar.aspx page and proceed as follows:

Although this example doesn’t do any useful work (such as updating a database or sending mail), it does illustrate the power of Web server controls and the way that Web Form events can add interactivity to your pages. As for updating databases and sending mail, that’s what the rest of the book (after a few more preliminary topics) is all about.

The code for the complete Web page is as follows. As you review it, notice the complete absence of program code within the HTML. Moving all the program code out of the HTML and into a single code declaration block leads to a clean, optimal layout for HTML code and program code alike. A few extra comment lines separate the subroutines for readability.

<%@ Page Language="VB" Explicit="True" Debug="True"%>
<script runat="server">
Sub ddlMonth_Change(sender as Object, e As EventArgs)
  calDate.VisibleDate = New DateTime(txtYear.text, _
                            ddlMonth.SelectedIndex + 1, 1)

End Sub
' ----------------------------------------
Sub txtYear_Changed(sender as Object, e As EventArgs)
  calDate.VisibleDate = New DateTime(txtYear.text, _
                            ddlMonth.SelectedIndex + 1, 1)
End Sub
' ----------------------------------------
Sub calDate_MonthChanged(sender as Object, _
                         e As MonthChangedEventArgs)
  txtYear.text = e.NewDate.Year
  ddlMonth.SelectedIndex = e.NewDate.Month – 1
End Sub
' ----------------------------------------
Sub calDate_Changed(sender as Object, e As EventArgs)
  litDate.Text = "You selected: " & calDate.SelectedDate
End Sub
' ----------------------------------------
Sub Page_Load(sender as Object, e As EventArgs)
  If Page.IsPostBack Then
  Else
    calDate.SelectedDate = now()
    txtYear.text = calDate.SelectedDate.Year
    ddlMonth.SelectedIndex = calDate.SelectedDate.Month – 1
  End If
End Sub
</script>

<html>
<head>
<title>Select a Date</title>
<link rel="stylesheet" type="text/css" href="../normal.css">
</head>
<body>
<h2>Select a Date</h2>
<form runat="server">
<p><asp:DropDownList id="ddlMonth" runat="server"
        AutoPostBack="True"
        OnSelectedIndexChanged="ddlMonth_Change">
    <asp:ListItem value="1">January</asp:ListItem>
    <asp:ListItem value="2">February</asp:ListItem>
    <asp:ListItem value="3">March</asp:ListItem>
    <asp:ListItem value="4">April</asp:ListItem>
    <asp:ListItem value="5">May</asp:ListItem>
    <asp:ListItem value="6">June</asp:ListItem>
    <asp:ListItem value="7">July</asp:ListItem>
    <asp:ListItem value="8">August</asp:ListItem>
    <asp:ListItem value="9">September</asp:ListItem>
    <asp:ListItem value="10">October</asp:ListItem>
    <asp:ListItem value="11">November</asp:ListItem>
    <asp:ListItem value="12">December</asp:ListItem>
  </asp:DropDownList>
  <asp:TextBox id="txtYear" runat="server"
       AutoPostBack="True"
       Columns="6"
       MaxLength="4"
       OnTextChanged="txtYear_Changed"/></p>
<p><asp:calendar id="calDate" runat="server"
        OnVisibleMonthChanged="calDate_MonthChanged"
        OnSelectionChanged="calDate_Changed" /></p>
<p><asp:literal id="litDate" runat="server" /></p>
</form>
</body>
</html>

The following procedure will modify the calendar.aspx page from the previous examples to display how many times a postback to the same page has occurred. This new information appears as the last line in the Web page that appears in the following graphic:

To add this feature to the calendar.aspx page, proceed as follows. If you’d rather look at the finished code, open the calendar2.aspx page in the ch04 folder that you installed from the companion CD.

Note that the Web page doesn’t increment the count when you click the browser’s Refresh button, even though ASP.NET executes the page again. ASP.NET saves all ViewState information in a hidden form field, and when you click the Refresh button, the browser transmits the previous form field values instead of the current ones.

In your testing of the calendar.aspx page and its descendants, you may have noticed that entering an invalid year causes the page to terminate with an error. In fact, ASP.NET years must be integers between 1 and 9999. This exercise will modify the calendar2.aspx page so that if the visitor enters an invalid year, the page will display an informative message like the one in the figure rather than a system-generated error page.

Proceed as follows if you wish to add this feature to the calendar2.aspx page. If you’d rather look at the finished code, open the calendar3.aspx page in the ch04 folder you installed from the companion CD.

A complete code listing for the calendar3.aspx page follows. The lines added in this procedure appear in blue.

<%@ Page Language="VB" Explicit="True" Debug="True"%>
<script runat="server">
Sub ddlMonth_Change(sender as Object, e As EventArgs)
  If Page.IsValid Then
    calDate.VisibleDate = New DateTime(txtYear.text, _
                              ddlMonth.SelectedIndex + 1, 1)
  End If
End Sub
' ----------------------------------------
Sub txtYear_Changed(sender as Object, e As EventArgs)
  If Page.IsValid Then
    calDate.VisibleDate = New DateTime(txtYear.text, _
                              ddlMonth.SelectedIndex + 1, 1)
  End If
End Sub
' ----------------------------------------
Sub calDate_MonthChanged(sender as Object, _
                         e As MonthChangedEventArgs)
  txtYear.text = e.NewDate.Year
  valYear.Validate
  ddlMonth.SelectedIndex = e.NewDate.Month – 1
End Sub
' ----------------------------------------
Sub calDate_Changed(sender as Object, e As EventArgs)
  litDate.Text = "You selected: " & calDate.SelectedDate
End Sub
' ----------------------------------------
Sub Page_Load(sender as Object, e As EventArgs)
  Dim intPostBackCnt As Integer
  Page.Validate
  If Page.IsPostBack Then
    intPostBackCnt = ViewState("PostBackCnt")
    intPostBackCnt = intPostBackCnt + 1
    litPostBacks.Text = "Number of postbacks: " & _
                          intPostBackCnt
    ViewState("PostBackCnt") = intPostBackCnt
  Else
    calDate.SelectedDate = now()
    txtYear.text = calDate.SelectedDate.Year
    ddlMonth.SelectedIndex = calDate.SelectedDate.Month – 1
  End If
End Sub
</script>
<html>
<head>
<title>Select a Date</title>
<link rel="stylesheet" type="text/css" href="../normal.css">
</head>
<body>
<h2>Select a Date</h2>
<form runat="server">
<p><asp:DropDownList id="ddlMonth" runat="server"
        AutoPostBack="True"
        OnSelectedIndexChanged="ddlMonth_Change">
    <asp:ListItem value="1">January</asp:ListItem>
    <asp:ListItem value="2">February</asp:ListItem>
    <asp:ListItem value="3">March</asp:ListItem>
    <asp:ListItem value="4">April</asp:ListItem>
    <asp:ListItem value="5">May</asp:ListItem>
    <asp:ListItem value="6">June</asp:ListItem>
    <asp:ListItem value="7">July</asp:ListItem>
    <asp:ListItem value="8">August</asp:ListItem>
    <asp:ListItem value="9">September</asp:ListItem>
    <asp:ListItem value="10">October</asp:ListItem>
    <asp:ListItem value="11">November</asp:ListItem>
    <asp:ListItem value="12">December</asp:ListItem>
  </asp:DropDownList>
  <asp:TextBox id="txtYear" runat="server"
       AutoPostBack="True"
       Columns="6"
       MaxLength="4"
       OnTextChanged="txtYear_Changed"/>
  <asp:RangeValidator id="valYear" runat="server"
       ControlToValidate="txtYear"
       Type="integer"
       MinimumValue="1"
       MaximumValue="9999"
       Display="Dynamic"
       ErrorMessage="Year is invalid." /></p>
<p><asp:calendar id="calDate" runat="server"
        OnVisibleMonthChanged="calDate_MonthChanged"
        OnSelectionChanged="calDate_Changed" /></p>
<p><asp:literal id="litDate" runat="server" /></p>
<p><asp:literal id="litPostBacks" runat="server" /></p>
</form>
</body>
</html>

Events that require a round trip to the server for processing can noticeably slow down the performance of a form. This performance hit is especially obvious, of course, if communication links are slow or the Web server is heavily loaded. Therefore, server controls react to a limited number of events:

ASP.NET doesn’t support events like onMouseOver that occur often and generally without the user knowing it. If you want to use these events, do so outside the scope of ASP.NET; that is, with traditional browser-side code.

Event handlers for both Web server controls and HTML server controls should always expect to receive two arguments:

If you specify the wrong type of object as an event handler’s second argument, you’ll generally get an error message. Fortunately, these messages usually include the name of the correct object. Fixing the problem is therefore as easy as copying the correct object name out of the error message and pasting it into your code.

In the case of Web server controls, by default, only button click events cause a postback to the server. If change events occur, browser-side code detects them, saves them up, and transmits them all to the server the next time a click event occurs.

On the server, ASP.NET will invoke the change event handlers in random order. All change event handlers must finish, however, before ASP.NET runs the click event handler. If you want change events for a Web server control to cause an immediate postback, code the AutoPostBack="True" attribute.

Never create application logic that relies on the change event handlers running in a specific order.

Web server controls such as the Repeater, DataList, and DataGrid create variable amounts of repetitive content. This content can contain "child" controls that raise events. For example, each row in a DataGrid can contain one or more buttons, each of which can raise events. Without knowing how many rows the DataGrid contains, it simply isn’t practical to code separate event handlers for each button.

To deal with this problem, ASP.NET "bubbles" any events from the child controls—that is, it sends them all to the Repeater, DataList, or DataGrid control that contains them. ASP.NET calls these controls containers. The container then raises a generic event called ItemCommand with parameters that point to the child control that actually raised the event. By responding to this single event, you can avoid writing event handlers for each child control.

The ItemCommand event supplies the same two arguments as any other event:

Sub datGrid1_ItemCommand (sender As Object, e As EventArgs)

The sender argument points to the child object that originally raised the event. The e argument points to an object that contains specific information about the event.

The DataGrid and DataList controls support additional events, such as EditCommand and DeleteCommand, which are special cases of bubbled events. For a working example that uses event bubbling with a Repeater control, refer to Chapter 8.

Web server controls support only server-side events. However, the core set of HTML server controls (buttons and text boxes) permit creating event handlers for both client events and server events. As with events for Web server controls, the server-side events for HTML controls are usually limited to a single event, such as Click or Change. The remaining events are available for use in client scripts.

Consider, for example, an ImageButton HTML server control. This is a picture configured so that clicking it submits a Web Form. In all likelihood, you would handle this control’s Click event with server-side code. (Otherwise, why make it a server control in the first place?)

Suppose, however, that you want to write some client-side code that changes the control’s picture whenever the mouse passes over it. To do this, you would add a perfectly ordinary onMouseOver attribute to the image button’s HTML, specifying the name of a JavaScript function that changes the picture. No conflict occurs because ASP.NET makes no use of the onMouseOver event.

Problems arise, however, if you try to create client-side and server-side event handlers for the same event. If, for example, you specify both an onServerClick (server-side) event handler and an onClick (client-side) event-handler for the same HTML button, ASP.NET will discard the onClick event handler. You can have only one event handler per event, and ASP.NET obviously favors the ASP.NET one.