Web Forms Controls
When we created the Calculator1 Web Forms page, we used special controls that are part of the Web Forms page architecture: the ASP.NET server controls. Server controls are the programmable elements in your page that provide you with the kind of behavior you expect from forms controls—programmable user interface, properties and methods, event-based programming, and so on—within the context of Web Forms. When a control runs, its specific job is to render some output, typically HTML, that’s contributed to the page output.
Many of the Web server controls fulfill almost the same roles in a Web Forms page that equivalent controls do in a Windows Form. Table 20-1 lists the Web server controls for a standard user interface.
|
Control |
Description |
|
Label |
Displays text that can be changed programmatically. |
|
Literal |
Similar to the Label control, but more lightweight, with fewer properties. |
|
TextBox |
Allows entry of text or passwords. Supports single-line or multiline entry and display. |
|
Button |
Submits the page to the server. Is rendered as a standard Windows button. |
|
LinkButton |
Submits the page, but is rendered as a hyperlink. |
|
ImageButton |
Submits the page, but is rendered as a graphic. |
|
HyperLink |
Displays a hyperlink that can be configured programmatically. |
|
DropDownList |
Displays a drop-down list of static items or items added at run time. |
|
ListBox |
Displays a list box of static items or items added at run time. |
|
CheckBox |
Allows a boolean choice that can be set programmatically. |
|
RadioButton |
Displays a single radio button that can be set programmatically. |
|
Image |
Displays a graphic that can be set programmatically. |
|
Panel |
Provides an area on the page that can have its own settings (such as color) and that can act as the container for other controls. |
|
Placeholder |
Provides a container for other controls. Unlike the Panel control, has no properties of its own. |
All Web server controls can be bound to a data source—for example, you can bind a TextBox or a ListBox control to a data source. However, some controls exist only to display data; these controls are listed in Table 20-2. Data binding is discussed later in this chapter, in the section “Working with Data in Web Forms.”
|
Control |
Description |
|
DataGrid |
Displays data from any data source (database, dataset, or other data structure) in a grid. Includes facilities for adding, sorting, and paging. |
|
DataList |
Displays data in a user-specified structure such as a table or a bulleted list. Supports editing. |
|
Repeater |
Displays data in a user-specified recurring structure such as a table, a bulleted list, or even a comma-delimited list. |
|
CheckBoxList |
Displays a group of check boxes that are typically bound to data. |
|
RadioButtonList |
Displays a group of radio buttons that are typically bound to data. |
You can add controls to a Web Forms page that automatically test what a user has typed into a text box, based on criteria that you specify. These controls are listed in Table 20-3.
|
Control |
Description |
|
RequiredFieldValidator |
Raises an error if a specific text control is left blank. |
|
CompareValidator |
Compares the value of a text control against a specified value using Boolean operators. Raises an error if the comparison returns false. |
|
RangeValidator |
Raises an error if the value in a text field falls outside a specified range. |
|
RegularExpressionValidator |
Raises an error if the value in a text field doesn’t match a pattern specified using a regular expression. |
|
CustomValidator |
Calls custom logic and raises an error based on the return value. |
|
ValidationSummary |
Displays text of validation errors in one location. |
Among the Web server controls are a handful designed for specific functions, as described in Table 20-4.
Web server controls all derive from a base WebControl class defined in the System.Web.UI.WebControls namespace. This class provides basic properties for all the controls, such as their BackColor, Width, and Enabled properties. Each control class provides the additional members for the control.
When you add a Web server control to a page, the Web Forms Designer adds an instance of the control class to the page. For example, in the Calculator1 example, the Web Forms Designer added the following members for the buttons on the page:
public class Calculator1 : System.Web.UI.Page
{
protected System.Web.UI.WebControls.Button SubtractButton;
protected System.Web.UI.WebControls.Button AddButton;
protected System.Web.UI.WebControls.Button MultiplyButton;
protected System.Web.UI.WebControls.Button DivideButton;
}
The page acts as the control’s container. It has a Controls collection, which is a collection of the controls defined on the page.
If you compare equivalent controls in Windows Forms and Web Forms, you’ll notice that the Windows Forms controls have dozens of events. In contrast, Web Forms controls have fewer events. For example, the Windows Forms Button control has not just the Click event, but also drag and drop events, mouse events, move events, and so on. In contrast, the Web Forms Button control has, for most practical purposes, variations on only a single event: Click.
This discrepancy again underscores the different processing model for Web Forms. The basic purpose of a Web Forms button is to submit the page to the server, so the only event you really care about is something like the Click event. It doesn’t make sense for the Button Web server control to expose (for example) a Mouseover event because you wouldn’t want to send the page to the server each time the user moved the mouse over the button. You can use client script for these kinds of functions if you need them in your page.
In fact, to say that Web Forms pages have events at all is something of an artifice. In Web processing generally, when a page is submitted to the server, there’s no real event. The browser simply sends a string (the HTTP request) to the server containing information such as the name of the process to call and the values of any controls on the page. The ASP.NET architecture takes this comparatively primitive information and translates it into a processing model that works much like true event handling in a Windows Form.
As mentioned, when you use the Visual Studio .NET Web Forms Designer to create an event handler for a control, the designer creates the event wireup and an event handling method. The method signature is the typical signature for events in the .NET Framework, passing a reference to the originating object and an instance of the appropriate event argument object. For example, this is the signature for a button’s Click event:
private void AddButton_Click(object sender, System.EventArgs e){ }
When a Button server control is clicked, it immediately posts the page to the server. Not all Web server controls immediately post the page back, however. For example, the DropDownList and ListBox controls expose a SelectedIndexChanged event that’s raised to indicate that the user has selected something in the control. By default, when this event occurs, the page isn’t immediately posted. Instead, the event is “cached” until another event posts the page, such as a Button control’s Click event. Only when the page is posted is the SelectedIndexChanged event handler called, followed by the button’s Click event.
All controls can post the page immediately and raise their event if you set their AutoPostBack property to true. This technique is useful, for example, when a user’s selection in a list box affects the contents of other controls.
