The RIGHT Way to Use Checkboxes in a .NET Repeater!

Update

It's one year later. I've gained some architectural insight, and to those who've been critical of this approach, I see your point. That said, the code here does work properly -  it's just highly inelegant.

Introduction 

ASP.NET server controls are designed to allow for event-driven programming and stateful behavior in the inherently stateless environment of the web. This is a good thing as it frees the programmer from having to parse Forms and QueryStrings and instead allows the developer to address visual elements on the page (i.e. text fields, drop down lists, labels, etc.) the same way you would deal with elements in a desktop application. The result is a huge savings of time, a nearly complete separation of UI and code, and an application that is far easier to debug.

Unfortunately, many of these controls are buggy and/or have missing features. Most notably, the <asp:CheckBox> control.

A common scenario in web development involves a list of checkboxes next to a bunch of items in a form. After submission of the form, the checked items are dealt with in some way (i.e. multiple deletion of messages in Hotmail.) Due to limitations in the CheckBox server control and a lack of documentation surrounding the proper use of Repeaters, developers have historically dealt with this problem by using a client side CheckBox, JavaScript, and an old-school cross page form post.

Background

The problem is fundamentally this: server side CheckBox controls lack a "Value" attribute. Therefore, it is difficult to use them with dynamically generated lists of data in a Repeater, as there is no straightforward way to determine which checkboxes represent which data item after the form is posted back.

There have been many solutions posted on the web which involve re-evaluating each data item in the repeater after PostBack using a looping approach. This method is error prone (such as with forward only readers) as well as being inefficient. The method I present here instead retrieves the data only once, stores it in a hidden server control paired with the checkbox, and allows for quick and easy retrieval on PostBack.

The Example

The following snippets show a typical example where a customer list is displayed, with a checkbox next to each customer. After the user clicks a button, messages are sent only to the customers who they have checked off.

The Front-End Code

 <asp:Repeater id="customerList" runat="server">
 <ItemTemplate>
    <%# Eval("name") %><br />  <!-- Their name -->
    <%# Eval("email") %><br /> <!-- Their email -->
    Send mailing list invite <asp:CheckBox id="selectUser" runat="server">
    <!-- Line below is key -->
    <asp:HiddenField ID="hiddenEmail" Value ='<%#Eval("email")%>'>
 </ItemTemplate>
 </asp:Repeater>

 <asp:Button Text="Send Message" OnClick="DoSend" Runat="server" />

What we have done here is place an invisible server control, the asp:HiddenField, inside the Repeater template. Since this control DOES allow a value to be assigned to it, we can now determine which checkbox is linked to which row.

To retrieve the email addresses associated with the checked items after PostBack, we need only to use a simple loop, as follows:

The Code-Behind

public void DoSend(object sender, EventArgs e)
{
    foreach (RepeaterItem i in customerList.Items)
       {                    
          //Retrieve the state of the CheckBox
          CheckBox cb = (CheckBox)i.FindControl("selectUser");
          if (cb.Checked)
          {
               //Retrieve the value associated with that CheckBox
               HiddenField hiddenEmail = (HiddenField)i.FindControl("hiddenEmail");

               //Now we can use that value to do whatever we want
               SendWelcomeMessage(hiddenEmail.Value);
          }
       }
} 

And that's all, folks! May the "I want to bang my head against the wall because I can't use a checkbox insider a repeater" phenomenon be but a distant memory.

Points of Interest

Microsoft has put a lot of work into its GridView control (for example, this particular problem is not an issue there) but really neglected its Repeater, which hasn't even changed significantly since ASP.NET 2.0.

Many coders choose the GridView over the Repeater partly for this reason. Repeaters are far more lightweight, and allow for full control over what is rendered. Hopefully this workaround will help to encourage its use.