Main Page

Client and Server HTML Controls

There are two ways to work with these controls—in the client browser (HTML client controls) and in the server (HTML server controls). In the client, you must use a scripting language, such as JavaScript. You can make these controls run at the server and so handle them with Visual Basic code, but they only support very limited events that can be handled on the server—typically, just an event named ServerClick or ServerChange (to differentiate them from the Click or Change events that are handled in the browser).

You can find the HTML controls available in the Visual Basic toolbox when you click the HTML tab (as opposed to the Web Forms tab we've been using up to now). It's important to start off by noting that, although these controls are client HTML controls run in the browser by default, you can turn any HTML control into an HTML server control—whose events are handled back at the server—by right-clicking them in a Web page and selecting the Run As Server Control menu item.

I'll take a look at working with these controls in the client, using JavaScript, to show how it's done, but our topic is Visual Basic, of course, so for the most part, we'll work with these controls in Visual Basic on the server. (When you specify that these controls should be handled back on the server as HTML server controls, they become available not only in the Web page's .aspx file, but also in the .aspx.vb file you can work with in a code designer.) If you want an in-depth treatment of working with HTML controls and JavaScript, take a look at the Coriolis HTML Black Book, which has three full chapters on the topic and teaches JavaScript along the way, not assuming any prior JavaScript knowledge.

When you add an HTML control to a Web form, by default, it's an HTML client control and only available for scripting in the Web page itself. To make it available to script code in the browser, you must give it an ID value, which you do with the (id) property in the Properties window; you can then refer to the control by ID in your script code.

When you turn the control into an HTML server control, on the other hand, Visual Basic gives it a default name, as it does with other controls you can access in Visual Basic code—although those names might be different than what you might expect. For example, the first text field gets the name Text1 (not TextBox1), the first radio button the name Radio1 (not RadioButton1), and so on. You can use this name to refer to the control in your Visual Basic code on the server; the control will have a Name property that holds this name. In other words, you use a control's ID in client code, and its Name in server-side code; for HTML server controls, these values are the same by default.

Some, but certainly not all, attributes of the HTML controls we'll work with become properties that you also can work with in Visual Basic code back on the server. You can, however, access all the HTML attributes of these controls using their Attributes property, which holds a collection of their HTML attributes, as we'll look at in this chapter. Keep in mind that not all attributes will be handled by all browsers. To see which attributes are handled in which browser, see the htmlref.html document on the CD-ROM. We'll see that these controls support fewer properties than the Web server controls we've been working with already, and which were specifically designed for Visual Basic .NET; the controls in this chapter are derived from the HtmlControl class, not the WebControl class.

Here's another thing to realize—these controls have no AutoPostBack property, which means that events have to wait to be processed until the user clicks a standard button or a Submit button, just as in other, standard Web pages you see on the Internet. So don't forget to add a Submit button to the pages you construct with these controls. You can create a Submit button with the Submit button tool in the toolbox—no additional code needed—so when the button is clicked, it'll send the page back to the server for processing. In addition, all values are stored as strings in HTML documents, so there's no data type safety here, and, because everything is available in the browser, there's a lot less security. On the other hand, using HTML controls is good when you want to handle a control both on the server and in the client, because you can write code for the same control in both locations.

You can see a number of the HTML server controls we'll discuss in this chapter in the HTMLControls example on the CD-ROM, which you see in Figure 19.1.