Practical ASP.NET

Working with the ListView

The ListView is the most powerful of the DataView controls and the hardest to work with. Here's how to minimize the pain while getting all the benefits.

It's no secret that I'm a very big fan of visual designers which is probably why I don't use the ListView control enough: No visual designer. That's too bad because the ListView is, without a doubt, the most powerful control in the Data section of the toolbox. While the GridView lets you display multiple rows at once and the FormView gives you control over the display format, only the ListView lets you do both: Display multiple rows at the same time using any format you want.

When you drag a ListView onto the page you get a gray box in design view. The first step in setting it up is to configure a DataSource and link the DataSource to the ListView. You still get a gray box. To actually get something to display you have to pick Configure ListView from the ListView's SmartTag. In the resulting dialog you can select a layout, a style, and whether or not to turn on paging (if you turn on paging you get a choice between two different paging styles). These choices will generate some default templates for your ListView and is infinitely preferable to creating them yourself.

Once you get the templates generated, you'll actually get a display that shows something: What the control will look like (sort of) when initially displayed in the browser -- it's called the "Runtime View." You won't get a visual designer for adding and removing controls from the ListView's templates as you would with, for instance, the FormView or templated columns in the GridView. Actually, that's not strictly true: You do get a visual designer for the empty template. For any template that displays data, though, you'll need to go into Source View.

In Source View you'll find a set of templates with some very old school tables inserted and controls inside the cells of the table. Here's a typical ItemTemplate with a set of Label controls bound to properties or fields from the DataSource that this ListView is bound to:

<asp:ListView ID="ListView1" runat="server" 
              DataSourceID="MyDataSource">
<ItemTemplate>
  <tr style="background-color:#DCDCDC;color: #000000;">
    <td>
      <asp:Label ID="CustomerIdLabel" runat="server" 
                 Text='<%# Eval("CustomerId") %>' />
    </td>
    <td>
      <asp:Label ID="CompanyNameLabel" runat="server" 
                 Text='<%# Eval("CompanyName") %>' />
    </td>
  </tr>
 </ItemTemplate>
 ... more templates... 
<asp:ListView>

The updateable templates (InsertItemTemplate and EditItemTemplate) vary from the ItemTemplate in two ways: they use updateable controls (e.g. a TextBox instead of a Label) and use the Bind function instead of the Eval function (the Bind function supports two-way databinding). A typical entry in the EditItemTemplate would look like this:

<asp:TextBox ID="ContactNameTextBox" runat="server" 
             Text='<%# Bind("ContactName") %>' />

You can replace the default controls with your own controls in Source View and you're no way obligated to use tables to lay out your templates. Effectively, you can treat each template as a mini-form that will be repeated for every row you retrieve from your DataSource.

For instance, if you're retrieving a Boolean field you'll want to replace the default TextBox generated with the templates with a more appropriate CheckBox. The resulting tag would look like this but you'll have to type it in yourself:

<asp:CheckBox ID="CompanyActiveCheckBox" runat="server" 
              Checked='<%# Eval("Active") %>' />

You could, of course, drag in a CheckBox control but, quite frankly, it adds so little text that it's faster just to modify the default tags added for you. Fortunately, adding or replacing controls in the ListView is the most difficult part of using the ListView. No, really.

For instance, adding Validators to the ListView isn't any more difficult in Source View as compared to Design View. You still drag the Validator into the ListView and drop it beside the control you want to validate. And you can still, fortunately, set the properties on the Validator control in the Property window.

I've been ignoring some key issues with the ListView: How to build your headings, turn on editing and using databound controls. I'll look at them in my next column.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.

comments powered by Disqus

Featured

  • VS Code 1.123 Adds Agent Session Sync, 1M Context Windows

    Microsoft released Visual Studio Code 1.123 on June 3, adding agent-focused features, larger model context support, integrated browser updates and a new delay for some automatic extension updates.

  • Copilot Billing Shock Hits Developers

    Developer complaints about GitHub Copilot's new usage-based billing model have centered on unexpectedly rapid AI credit consumption, and neither GitHub nor Microsoft has responded directly to the backlash, though they have previously published guidance to lessen model usage costs.

  • Hands On with GitHub Copilot App Technical Preview: Turning a Blazor Issue into a PR

    GitHub's brand-new Copilot desktop app, in technical preview, handled a small Blazor issue from planning through pull request creation, but the hands-on test also showed why developers still need to verify agent work in the running app before merging.

  • At Build 2026, Microsoft Sets Up Windows as an OS for AI Agents

    Microsoft's Build 2026 Windows developer announcements point to a broader platform strategy for agentic AI, spanning terminal workflows, local models, app-building skills, Cloud PCs and operating system-level containment.

Subscribe on YouTube