Like every Web control in the ASP.NET toolbox, the GridView includes a variety of style-related properties, including CssClass, Font, ForeColor, BackColor, Width, Height, and so on. The GridView also includes style properties that apply to certain classes of rows in the grid, such as RowStyle, AlternatingRowStyle, HeaderStyle, and PagerStyle. Each of these meta-style properties offer the standard style properties (CssClass, Font, etc.) as subproperties.

In ASP.NET 4.0, Microsoft added four new style properties to the GridView control: SortedAscendingHeaderStyle, SortedAscendingCellStyle, SortedDescendingHeaderStyle, and SortedDescendingCellStyle. These four properties are meta-style properties like RowStyle and HeaderStyle, but apply to column of cells rather than a row. These properties only apply when the GridView is sorted - if the grid's data is sorted in ascending order then the SortedAscendingHeaderStyle and SortedAscendingCellStyle properties define the styles for the column the data is sorted by. The SortedDescendingHeaderStyle and SortedDescendingCellStyle properties apply to the sorted column when the results are sorted in descending order.

These four new properties make it easier to customize the appearance of the column by which the data is sorted. Using these properties along with a touch of Cascading Style Sheets (CSS) it is possible to add up and down arrows to the sorted column's header to indicate whether the data is sorted in ascending or descending order. Likewise, these properties can be used to shade the sorted column or make its text bold. This article shows how to use these four new properties to style the sorted column. Read on to learn more!
Read More >

In the .NET Framework 3.5 SP1, Microsoft introduced ASP.NET Routing, which decouples the URL of a resource from the physical file on the web server. With ASP.NET Routing you, the developer, define routing rules map route patterns to a class that generates the content. For example, you might indicate that the URL Categories/CategoryName maps to a class that takes the CategoryName and generates HTML that lists that category's products in a grid. With such a mapping, users could view products for the Beverages category by visiting www.yoursite.com/Categories/Beverages.

In .NET 3.5 SP1, ASP.NET Routing was primarily designed for ASP.NET MVC applications, although as discussed in Using ASP.NET Routing Without ASP.NET MVC it is possible to implement ASP.NET Routing in a Web Forms application, as well. However, implementing ASP.NET Routing in a Web Forms application involves a bit of seemingly excessive legwork. In a Web Forms scenario we typically want to map a routing pattern to an actual ASP.NET page. To do so we need to create a route handler class that is invoked when the routing URL is requested and, in a sense, dispatches the request to the appropriate ASP.NET page. For instance, to map a route to a physical file, such as mapping Categories/CategoryName to ShowProductsByCategory.aspx - requires three steps: (1) Define the mapping in Global.asax, which maps a route pattern to a route handler class; (2) Create the route handler class, which is responsible for parsing the URL, storing any route parameters into some location that is accessible to the target page (such as HttpContext.Items), and returning an instance of the target page or HTTP Handler that handles the requested route; and (3) writing code in the target page to grab the route parameters and use them in rendering its content. Given how much effort it took to just read the preceding sentence (let alone write it) you can imagine that implementing ASP.NET Routing in a Web Forms application is not necessarily the most straightforward task.

The good news is that ASP.NET 4.0 has greatly simplified ASP.NET Routing for Web Form applications by adding a number of classes and helper methods that can be used to encapsulate the aforementioned complexity. With ASP.NET 4.0 it's easier to define the routing rules and there's no need to create a custom route handling class. This article details these enhancements. Read on to learn more!
Read More >

Filtering Database Data with Parameters, an earlier installment in this article series, showed how to filter the data returned by ASP.NET's data source controls. In a nutshell, the data source controls can include parameterized queries whose parameter values are defined via parameter controls. For example, the SqlDataSource can include a parameterized SelectCommand, such as: SELECT * FROM Books WHERE Price > @Price. Here, @Price is a parameter; the value for a parameter can be defined declaratively using a parameter control. ASP.NET offers a variety of parameter controls, including ones that use hard-coded values, ones that retrieve values from the querystring, and ones that retrieve values from session, and others.

Perhaps the most useful parameter control is the ControlParameter, which retrieves its value from a Web control on the page. Using the ControlParameter we can filter the data returned by the data source control based on the end user's input. While the ControlParameter works well with most types of Web controls, it does not work as expected with the CheckBoxList control. The ControlParameter is designed to retrieve a single property value from the specified Web control, but the CheckBoxList control does not have a property that returns all of the values of its selected items in a form that the CheckBoxList control can use. Moreover, if you are using the selected CheckBoxList items to query a database you'll quickly find that SQL does not offer out of the box functionality for filtering results based on a user-supplied list of filter criteria.

The good news is that with a little bit of effort it is possible to filter data based on the end user's selections in a CheckBoxList control. This article starts with a look at how to get SQL to filter data based on a user-supplied, comma-delimited list of values. Next, it shows how to programmatically construct a comma-delimited list that represents the selected CheckBoxList values and pass that list into the SQL query. Finally, we'll explore creating a custom parameter control to handle this logic declaratively. Read on to learn more!
Read More >

The previous installment in this ongoing article series showed how to configure the DataPager control to generate an SEO-friendly paging interface. By default, the DataPager renders its paging interface as a series of Buttons, LinkButtons, or ImageButtons that, when clicked, trigger a postback. The problem with postbacks is that they are not crawled by search engine spiders, meaning that with the default behavior only the first page of data will make it into the search engines' indexes. Fortunately, the DataPager's paging interface can be configured to include the page number in the querystring. When configured this way, the DataPager renders its paging interface using hyperlinks with URLs like Products.aspx?Page=PageNumber. With this approach a search engine will happily crawl through each page of data.

Shortly after publishing Creating an SEO-Friendly Paging Interface, a number of readers asked if it would be possible to create a paging interface that moved the page number from the querystring into the URL. Rather than having a paging interface that linked to pages with URLs like Products.aspx?Page=PageNumber, these readers wanted to have URLs like: Products/PageNumber. Such terse, descriptive URLs are possible with ASP.NET Routing, a feature added to the .NET Framework 3.5 SP1. While typically used in ASP.NET MVC applications, ASP.NET Routing can also be used in Web Form applications.

This article shows how to use ASP.NET Routing with the ListView and DataPager controls to create the ultimate paging interface. Read on to learn more!
Read More >

The GridView, FormView, and DetailsView controls all contain built-in paging functionality. By setting a few properties, it's possible to have any of these controls automatically include a paging interface. The ListView, however, does not include built-in paging functionality. Instead, Microsoft decoupled the paging logic from the ListView and moved it into a separate Web control - the DataPager. Paging Through Data with the ListView and DataPager Controls, an earlier article in this series, explored how to use the DataPager to implement a paging interface for the ListView.

By default, the DataPager renders Buttons, LinkButtons, or ImageButtons in the paging interface for the Next, Previous, First, Last, and numeric page number buttons. When clicked, these buttons cause a postback, at which point the appropriate set of records are bound to the ListView. Unfortunately, search engines cannot crawl a site using postbacks; instead, they rely on links they find on your site. Consequently, a search engine will only index the first page of data displayed by a ListView, because it cannot reach the subsequent pages. Also, users cannot bookmark a particular page of data.

The good news is that it is quite easy to modify the DataPager's default behavior. This article shows how to configure the DataPager to use hyperlinks and the querystring to page through a ListView's data (rather than postbacks) to create an SEO-friendly paging interface. Read on to learn more!
Read More >

The end of the year is upon us, 2009 is about to be in the books. When closing out a year I like to take a look back at the articles I wrote over the year and see which ones resonated the most with readers. Which ones generated the most reader emails? Which ones were read the most? Such a retrospective analysis highlights what content was of most interest to developers in the trenches, and this data is used to guide article topics in the new year.

While cataloging this year's most popular articles I thought others might find the data interesting. Such a "Best Of 2009" list would give both regular and new readers a chance to discover (or rediscover) the most favored content from the year. So here it is - a list and synopsis of the 2009's most popular articles on 4GuysFromRolla.com.
Read More >

Charts are typically used to provide a static snapshot of data. The chart's underlying data might be based on various user inputs, but in the end the chart, once rendered, represents the end of the reporting workflow. However, other scenarios allow for a more interactive user experience. For example, in the Creating Drill Down Reports article we looked at how to configure the Chart control to allow the user to drill into a particular data point. Specifically, the demo contained a column chart showing the number of products in each category in the Northwind database. Clicking on a column whisked the user to a new page that details about the products in that category. Also, in certain situations the data populating the chart might be arriving from a sensor or some other source that is constantly being updated. In that case, we might want a real time chart whose data is periodically (and automatically) refreshed to show the latest data.

Ajax is a set of related techniques used in websites to build more interactive and responsive applications. Microsoft's ASP.NET Ajax Framework offers developers both server- and client-side frameworks for developing Ajax-enabled applications. This article looks at how to use Ajax with the Microsoft Chart controls, focusing on two demos. In the first we'll create a drill down report with a column chart that shows the gross sales per month for a particular category and fiscal year. The user can click on a particular column in the chart to see the breakdown of sales per day in that month on the same page. This breakdown is displayed in an UpdatePanel, and clicking on a column in the chart triggers an asynchronous postback. The other demo looks at using the Timer control to render a real time chart.

Read on to learn more!
Read More >