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

How to generate checkboxes corresponding to items in a repeater, and how to retrieve their state on PostBack

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.

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

publicvoid 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.

Share

About the Author

Sam Rahimi currently leads the web team at World Golf Tour (www.wgt.com) and has an extensive background in ASP.NET, specializing in social networking and casual gaming.

Previously, he has worked for Roblox Corporation on their unique children's MMO as well as spending two years as team lead at Supernova.com, helping bring their social networking site into the modern era and doubling traffic along the way.

Sam started as a classic ASP engineer as a summer job 6 years ago to make some money to pay for tuition - to finish a degree in political science - and needless to say, never looked back. His experience has lead him to gain additional experience in the mobile space - J2ME, Android app developmentm, and SMS protocols.

And sure, the other engineers in SF may have an IPhone - Rahimi sticks with the EVO all the way!

First of all, thanks for your solution. I'm sorry people are so negative. I came up with the exact same solution as you did, and then happened upon your article. Once I saw all the "just use inheritance" posts I took a look at that and ended up discovering a simple answer via Google that doesn't require inherited controls or a hidden field.

Try the code below, which uses the InputAttributes collection of the control. You can access the value on postback via the collection since it's stored in the viewstate. Also if you check the HTML of your page you can see that the value attribute of the HTML checkbox is now correctly populated.

Why inherit from CheckBox to create a custom control when HtmlInputCheckBox already has a Value property and is standard. Sure, it lacks a few things the CheckBox control has but when working in a repeater as described in the article I don't need those features anyway.

Using the HtmlInputCheckBox eliminates the need for custom controls and hidden controls. Furthermore, it let's me work with JavaScript (if I need to) since I'm not hiding the value away in the View State.

publicvoid DoSend(object sender, EventArgs e)
{
foreach (RepeaterItem i in customerList.Items)
{
//Retrieve the state and value of the HtmlInputCheckBox
HtmlInputCheckBox cb = i.FindControl("selectUser") as HtmlInputCheckBox;
if (cb != null && cb.Checked)
{
//Now we can use that value to do whatever we want
SendWelcomeMessage(cb.Value);
}
}
}

Sure is not the correct way of use, but in my opinion is fast than inherit the checkbox and implement the custom attributes. This approach have the aspect that you send the personid to the client browser:

publicvoid Page_Load(object sender, EventArgs e)
{
//Attach to event. This attach method only works with .net 2.0. If you need the 1.1 version, please encapsulate the method into the RepeaterItemEventHandler delegate;
repeater1.ItemDataBound+=repeater1_ItemDataBound;
}
protectedvoid repeater1_ItemDataBound(object sender, RepeaterItemEventArgs e)
{
//find the right control to change its attributes
CheckBox chk = FindCheckBox(e.Item);
//Since we have the Attributes being set in the server side, the control persists them in the viewstate, so in the postback, it will be available.
chk.Attributes["PersonID"] = (e.DataItem as Person).PersonID.ToString();
}

Im almost sure this will work. If you try and resolves the problem, please let us know by updating the article.
Thanks for the article and sorry my awful english.