ASP.NET WebControl Critical Analysis: DropDownList

June 27, 2011 by Christoff Truter ASP.NET  

There is a lot of the common functionality when working with html controls that Microsoft simplified (some overcomplicated in my opinion) in order to fit into their WebForms framework.

This is my first post (of hopefully many to follow) where I am going to look at some of the common issues I've seen over the years with regards to webcontrols.

Note that I doubt that Microsoft see them as issues, since they didn't seem to endeavour to fix/improve any of this in the latest incarnation of the product, so all of these issues are likely by intended design.

The first control I am going to look at is the DropDownList webcontrol.

<asp:DropDownList runat="server" ID="ddlLetters">
	<asp:ListItem Text="A" Value="1"></asp:ListItem>
	<asp:ListItem Text="B" Value="2"></asp:ListItem>
	<asp:ListItem Text="C" Value="3" Selected="True"></asp:ListItem>
	<asp:ListItem Text="D" Value="4"></asp:ListItem>
</asp:DropDownList>

This control is an abstraction Microsoft created for the (X)HTML select list (the single selection part of it at least, they created a separate abstraction for the multiple selection - ListBox).

<select name="letters">
   <option value="1">A</option>
   <option value="2">B</option>
   <option selected="selected" value="3">C</option>
   <option value="4">D</option>
 </select>

1. OPTGROUPS
   
   Probably the most common issue is the fact that the DropDownList doesnt support optgroups.
   
   

   <select name="letters">
   	<optgroup label="Microsoft">
   	   <option value="1">C#</option>
   	   <option value="2">VB.net</option>
   	</optgroup>
   	<optgroup label="">
   	   <option value="3">PHP</option>
   	   <option value="4" disabled="disabled">Java</option>
   	   <option value="5">Perl</option>
   	</optgroup>
   </select>

   
   The optgroup tag is by no means deprecated or obsolete or anything, so I am not quite sure why they excluded this functionality. Incidently, I wrote a post a while ago on how to include this functionality by means of WebControlAdapters.
   
   
2. SELECTEDVALUE NOT BROWSABLE
   
   
   
   Not really an issue (but confusing to some) that the SelectedValue is not visible in the designer, the reason being that whoever wrote the ListControl base class (the class from which the DropDownList inherits from) set the Browsable attribute above the property to false.
   
   I've seen devs coding around this (sometimes with good reason, like seen in point 3) even though it is still possible to bind or eval the SelectedValue when using it within a parent control e.g. ListView, FormView etc.
   
   

   <asp:DropDownList runat="server" ID="ddlLetters" Selectedvalue='<%# Eval("somevalue") %>'>

   
   I do however believe that the developer(s) "hid" this property on purpose, I believe that the following issue might give us a clue to why (s)he did it.
   
   
3. SELECTEDVALUE MUST EXIST
   
   Chances are that you've come across the following exception:
   
   'ddlSomething' has a SelectedValue which is invalid because it does not exist in the list of items
   
   The reason we get this exception is obvious, our selected value needs to be in the list we're setting it to and its not.
   
   When working with lists that constantly change (add/removed/edited), or in certain binding scenarios one can easily get this exception but equally as easy to manage this exception in our codebehind / codefile, but it becomes problematic to trap this exception as soon as we're working with something like ObjectDataSources and we attempt to bind the SelectedValue like seen in point 2.
   
   We get forced to bind our SelectedValue in our DataBound event like seen below (something you can perhaps move to a WebControlAdapter).
   
   

   protected void ddlLetters_DataBound(object sender, EventArgs e)
   {
   // Depends on the context in which this event fires
       ((DropDownList)sender).SelectedValue = Convert.ToString(Eval("somevalue"));
   }

   
   Which means its safer to bind our SelectedValue in the codebehind making it prudent to rather hide the SelectedValue property from the designer.
   
   It would have probably made more sense to allow developers to specify a default item to which our SelectedValue must revert if its not found and if no default item is specified we simply throw the does not exist exception like normally.
   
   Note: This workaround won't work for all scenarios, perhaps we can look at other scenarios in a future post.
   
   
4. ITEM UNIQUENESS
   
   It makes sense to only list unique items in our DropDownList, but what happens if we list non-unique values? Meaning our Text/display is unique, but the value associated with it is not e.g:
   
   

   <asp:DropDownList runat="server" ID="ddlLetters">
       <asp:ListItem Text="A" Value="2"></asp:ListItem>
       <asp:ListItem Text="B" Value="1"></asp:ListItem>
       <asp:ListItem Text="C" Value="1"></asp:ListItem>
       <asp:ListItem Text="D" Value="4"></asp:ListItem>
   </asp:DropDownList>

   
   I remember helping someone with this very issue a few years ago (he wasted a good hour trying to figure this out, rather sad).
   
   Every time someone selected C it would highlight B after a postback since the control cant distinguish which value of "1" the user selected, so it assumed that the first value of "1" it finds is the selected one (he had a list containing 100 values)
   
   It would have saved that developer (who didn't realise that he's binding a non-unique valued list to the DropDownList) a whole hour of his time if the DropDownList simply threw an item uniqueness exception or something...

Feel free to comment on additional issues you've come across...