The <asp:dropdownlist> Control

The <asp:dropdownlist> control is one of the best controls for demonstrating the usefulness of having a form control processed on the server side.

Before we move on to the <asp:dropdownlist> control, let's pause to look at the HTML form control equivalent. Drop-down listboxes are implemented in HTML using the <select> and <option> tags. For each option, you would have a separate opening and closing <option> tag inside the <select> tag. A listbox can be defined in HTML as follows:

To create an ASP.NET drop-down list control that did exactly the same, you'd need to define it in the following way:

There are three important differences from the HTML form control:

q        The <asp:dropdownlist> tag directly replaces the <select> tag

q        The <asp:listitem> tag replaces the <option> tag

q        The id attribute replaces the name attribute

Up until now, in all HTML form controls, the name attribute has been used to pass the identity of the form control to the ASP.NET code. The id attribute, for all but form controls, provides exactly the same function for any other HTML tags. The server-side control is therefore being brought up to date, by using the id attribute to perform this function, rather than the name attribute.

The <asp:dropdownlist> control has many attributes to help customize its appearance. We're not going to describe them here – once again you can find out more details using the class browser tool.

Visually, the <asp:dropdownlist> control is identical to the HTML drop-down list control; it's what's going on behind the scenes that is different. The best way to explain this is to look at an example. We'll create a form that asks the user to select the particular holiday destination they wish to know more about.

1.       In your web page editor, type in the following:

2.       Save this as listpage.aspx this time, and run it in your browser:

3.       Select an option and click on Submit Query:

4.       Now click on the View menu and select Source. You should see something like the following. Don't worry if your version isn't exactly the same – the code has been tailored to your personal browser:

How It Works

This is our first real look at what the ASP.NET code has been doing. As you can see, everything that has been returned to the browser has been returned as HTML code. Also, note that we are using only one page, in direct contrast to our two-page approach with HTML forms. This is because the form page submits to itself. To explain how it works, we're going to reference the source code that we can view in our browser, and compare it to our original ASPX code.

Let's start by jumping into the <form> section of the script. The very first thing we do with the form is set a new attribute:

This tells ASP.NET that we intend this form to be run on the server. If we compare this line to what has been returned to the browser, we can see a large difference:

ASP.NET has generated four new attributes. The name and id attributes serve the same purpose, uniquely identifying the form, but it's the other two that are of interest. As we described earlier, HTML forms require a page to receive the form data, and a method of transmission. We didn't specify either of these in our ASPX code, so ASP.NET specified them for us. The action attribute actually points to the same page that we have run, so the answers are returned to our first page. It also specifies the POST method by default.

The main item on the form is the <asp:dropdownlist> control:

It's crucial to note how this is rendered. If you view the source code that's been sent back to the browser, you should see something like this:

The second half is just a <select> HTML form control; this is the HTML output of a dropdownlist.

Note that it's had one of the <option> tags altered to reflect the selection we made before we submitting the form.

However, it's the first line that is of particular note. This is a hidden control called __VIEWSTATE, whose value is an encoded representation of the overall state of the form (as it was when last submitted). This is used by ASP.NET to keep track of all the server control settings from one page refresh to another – otherwise, our drop-down listbox would revert to a static default setting every time we submitted a value.

It may not be immediately obvious how useful this can be – consider a registration form in which you have to enter a full set of personal details. If you forget to fill in a required field, and then submit the form, you may well be prompted with the same form again. Perhaps the field you missed will be highlighted, but unless the page has been very carefully coded (or is running on a sophisticated technology like ASP.NET), all the data you just entered will have to be typed in again. Thanks to __VIEWSTATE, all that data is automatically persisted through to the refreshed page, and we (as developers) haven't even to raise a finger!

We don't need to try to work out what the value contained in the value attribute is – it's only really designed to mean anything to ASP.NET itself. However, it's important to note that this attribute is what allows the form to keep track of the state of a server control between page moves and page refreshes. Indeed, when we ran through the example you might have noticed that even refreshing the page didn't alter the selection you'd made.

Part 1 : HTML Server Controls Part 2 : Simple Web Theory Part 3 : HTML Forms Part 4 : How the <form> Tag Works in ASP.NET Part 5 : Control Examples Part 6 : Control Attributes Part 7 : The asp:dropdownlist Control Part 8 : The ASP.NET Code Part 9 : The asp:listbox Control Part 10 : The asp:dropdownlist Control Part 11 : The asp:radiobuttonlist Control Part 12 : The asp:checkbox and asp:checkboxlist Control Part 13 : Summary Buy Beginning ASP.NET with C# here © Copyright 2002 Wrox Press This chapter is written by David Sussman, et al and taken from "Beginning ASP.NET with C#" published by Wrox Press Limited in June 2002; ISBN 1861007345; copyright © Wrox Press Limited 2002; all rights reserved. No part of these chapters may be reproduced, stored in a retrieval system or transmitted in any form or by any means -- electronic, electrostatic, mechanical, photocopying, recording or otherwise -- without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.