The folks at Trivium Technologies have released the first version of their MSBuild Sidekick, a GUI front end to MSBuild. Even though this tool probably cannot replace the productivity that I can currently attain by taking advantage of the Intellisense support in Visual Studio, I think it would have been a great asset when I was first starting out with MSBuild. It's also free, so there's no harm in checking it out.

One of the great things about the new ASP.NET GridView control is that it allows you to implement column field sorting with relative ease, at least in comparison to what you would have had to do to attain similar functionality in earlier versions. There are a plethora of articles and tutorials out there that lead you through this process, but one thing that most, if not all, of these are lacking is some kind of hint of how to override the default sorting order of your sortable columns. Since this was a problem that I had to solve recently and given the number of times I’ve seen the question being asked (and unanswered) across various forums and newsgroups, I figured I’d take some time to share my solution with the community.

This entry assumes that you have a good understanding of how sorting works in the DataGrid. If you don’t, I would suggest that you take some time to do so before continuing. There is no download, but I provide enough code for you to be able to implement this solution on your own grid.

The GridView control raises two sort-related events when the user clicks on a link button in the header of any columns that has its CommandName property set to Sort. The Sorting event is raised before the GridView handles the sort operation and the Sorted event is raised after the sorting has completed and data has been bound to the grid.

The Sorting event is of particular interest to us. By handling this event, we have the opportunity to manipulate the sort data before the grid hands it to the underlying data store (usually managed by an instance of ObjectDataSource) and asks for the data to be manipulated in a form that conforms to the sorting rules that it has established.

When the event is handled, we receive a reference to a GridViewSortEventArgs object which contains properties that contain values that we are interested in. The first is the SortExpression property, which, in the simplest of situations, contains the name of the field that is to be sorted. The second is the read-only SortDirection property which defines the order in which the data will be sorted. This actually serves no purpose in this space other than to provide assistance in identifying the eventuating sort direction.

Once the handler has completed its scope of execution, if the sort has not been cancelled by setting the Cancel property of the GridViewSortEventArgs object to true, an instance of DataSourceSelectArguments is created and the final sort expression is defined. The pertinent value is essentially a concatenation of the SortExpression value and the SQL equivalent of the SortDirection value if it is defined as SortDirection.Descending. In other words, given a column named (and sort expression defined as) Rating and a SortDirection value of SortDirection.Descending, the ultimate sort expression will be “Rating DESC.” If the SortDirection value is SortDirection.Ascending, the expression would be restricted to only the defined SortExpression, which would be “Rating.”

Now that we have attained this understanding, let’s take a look at how this can be manipulated to reverse the default sorting order.

protected void SearchResultsView_OnSorting( object sender, GridViewSortEventArgs e ) {
  e.SortExpression = e.SortExpression + " DESC"
}

In the above code block, I’ve overridden the SortExpression value that was captured at the time that the event was raised. Instead of the values in the column being sorted in ascending order, which, again, is the default, the expression has been defined as a concatenation of the original sort expression and DESC. Once the event has been handled, the updated SortExpression will be parsed and the SortDirection property on the grid will be updated as appropriate to match the order that you specified in the expression. What this means is that if the next sort is done on the same column, the SortDirection value will be SortDirection.Ascending instead of SortDirection.Descending.

The code would work great if you wanted the default (and only) sorting order of each of the sortable columns in your grid to be descending. This is clearly not the desirable outcome. Since we only want this exception to apply to the Rating expression, we’ll add some code that checks for this expression before overriding its default sort.

protected void SearchResultsView_OnSorting( ... ) {
  if ( e.SortExpression.Equals( "Rating" ) ) {
    e.SortExpression = e.SortExpression + " DESC";         
  }
}

We still want the contents of the Rating column to be sorted in ascending order, but only after the column has previously been sorted in descending order. To clarify, there are two different scenarios that we need to cover:

1. Sorting the Rating column when it's already in descending order should result in an ascending sort.
2. If a different column is sorted after the Rating column has been sorted, regardless of its order, the first sort of the Rating column afterwards should be descending.

The implementation is actually relatively simple. All we need to do is stash away the most recent expression in a state bag (ViewState) and load and compare it when the next Sorting event is handled. The following code demonstrates how we first check to make sure that the current sort expression is the Rating expression, then we check the value stored in the PreviousSortExpression key in ViewState to see if it was used in the previous sort. If it was, then the sorting is done based on the current SortDirection, otherwise it's forced to descending order.

protected void SearchResultsView_OnSorting( ... ) {

  string originalExpression = e.SortExpression;

  if ( e.SortExpression.Equals( "Rating" ) ) {

      if ( ViewState[ "PreviousSortExpression" ] == null || 
           !ViewState[ "PreviousSortExpression" ].ToString().Equals( originalExpression ) ) {
            
        e.SortExpression = e.SortExpression + " DESC";
        
      } 

   }

  ViewState[ "PreviousSortExpression" ] = originalExpression;

}

That does it. Happy Sorting!

My latest ASP.NET coding endeavor required that I perform a postback and then transfer control over to a different page (primarily for URL concealment purposes) using Server.Transfer. I needed to be able to pass values from the source page to the target page, but didn't really have a good way to do this. A quick gander at the documentation seemed to indicate that the way to do this was to define public properties on the source page, use the Handler property of the Context instance to retrieve a IHttpHandler-based reference to the source page which can then be cast to the source page type, providing you with access to all of the public properties, as shown in the following code block:

MyPage page = ( MyPage ) Context.Handler;
int num = page.MyPublicProperty;

A MSN search (yes, really) revealed several different approaches that people have taken to persist data across multiple pages within the same HTTP context (which essentially is one round-trip to the server). One person encouraged the practice of declaring public dictionaries that are persisted in similar fashion as the code above, others sanctioned the use of server side (session) cookies and some went as far as defining hidden field values and accessing them through the HttpValueCollection exposed by HttpRequest.Form on the target page.

I decided to take some time to go through all of the findings that I had come across and determine whether or not they would be of use. I've provided a brief summary of what I discovered as I went through each of the three different approaches that I found followed by my solution.

Declaring Public Properties

Declaring a public dictionary of values that I wanted to pass from the source page to the target page seemed to make sense, but I was still reluctant about exposing a public property in my Page class, especially when the only purpose that it would serve would be to pass this dictionary across connecting pages on the server. Additionally, this would create a strong coupling between pages that are involved in the transfer, which is something I really wanted to avoid. As an example, suppose I had three pages, A, B and C, each containing a Dictionary typed public property named Values, that were transferred to page Z. The code would look something like this:

Dictionary<int, string> valueDictionary;

if ( Context.Handler.GetType().Name.ToLower().Equals( "a_aspx" ) ) {
  valueDictionary = ( ( A ) Context.Handler ).Values;
} else if ( Context.Handler.GetType().Name.ToLower().Equals( "b_aspx" ) ) {
  valueDictionary = ( ( B ) Context.Handler ).Values;
} else if ( Context.Handler.GetType().Name.ToLower().Equals( "c_aspx" ) ) {
  valueDictionary = ( ( C ) Context.Handler ).Values;
} else {
  // they shouldn't be here. redirect them somewhere else.
}

// do something with valueDictionary

This kind of coupling would influence a required code change in Z if any of the following scenarios were to happen:

1. I decided that I wanted to transfer page D to Z.
2. I no longer wanted one or more of the pages to be transferred to Z.
3. One of the pages is no longer needed and is deleted from the web project.

Sessions

We have a policy that prohibits the use of sessions, so that was not something that I could use. Even if I could, I wouldn't unless it was as a last resort. Sessions, especially on a high-traffic site, can be expensive and should generally be avoided. They are also pretty much useless in a web farm because there isn't a clean way to persist them across multiple server instances in the cluster unless you have a centralized session server.

Hidden Form Fields

The HttpValueCollection exposed by HttpRequest.Form provides access to a collection of key-value pairs in which the identities of the controls (from Control.ClientID) on the source page are contained. In the case of passing data by way of hidden fields comes the requirement that you be able to retrieve a reference to the control on the server. The best way to do this is to retrieve a IHttpHandler based reference to the source page, casting it to the appropriate page type, invoking the FindControl() method on the source page instance and retrieving the control by the identifier defined on the web form and accessing its value. This presents two distinct problems. First, by doing this, you're creating the same strong coupling dependency as you would by declaring public properties. In addition to that, you will have to ensure that each page that is transferred to this target page has a control with the given ID of choice. Secondly, you're breaking the rules of encapsulation by using FindControl(). This, in the eyes of many, is not recommended practice. Let's not forget the potential performance hit that you could take by forcing a traversal of the control hierarchy.

Solution

I was a little bit frustrated at this point. The first option seemed like the only reasonable option, but intuition pushed me towards the HttpContext class in the .NET Framework Class Library documentation. I figured that since I was operating within a HttpContext that the class might expose a collection of some sort that would allow me to define values that would persist throughout the HTTP request. I stumbled across the Items property which immediately piqued my interest. You couldn't go wrong with a description that says, "Gets a key/value collection that can be used to organize and share data between an IHttpModule interface and an IHttpHandler interface during an HTTP request" could you? A fury of finger movement upon my keyboard resulted in the following code:

public partial class MyPage : Page {

  protected override void OnLoad( EventArgs e ) {

    Context.Items[ "SomeKey" ] = 5; 
    Server.Transfer( "target.aspx", true );

  }

}

public partial class TargetPage : Page {

  protected override void OnLoad( EventArgs e ) {

    if ( Context.Items[ "SomeKey" ] == null ) {
      // redirect
    }

    // use value of Context.Items[ "SomeKey" ]

  }

}

Mission accomplished. With this approach, the only thing that would need to be done in order to transfer a page to TargetPage would be to define the appropriate keys in the key/value collection exposed by Content.Items before initiating the transfer.

I just came across XAMLShare, a public wiki dedicated to providing various Windows Presentation Foundation (Avalon) code samples. There aren't many samples at the time, but hopefully the number will grow as WPF works its way into the mainstream.

One of the most common questions I've been asked in recent weeks has been in regards to creating a data grid column style that supports text wrapping. It's really unfortunate that the DataGrid control does not provide this type of functionality, and even more that achieving a such effect is such a daunting task that requires a thorough comprehension of the control's rendering infrastructure. Since this was a requirement for one of the tools that I'm currently working on, I had no choice but to sit down and endure some pain in attempting to make this happen. I just finished up a very rough slab of code that produces what is visible in the following screenshot:

 

Before you make a mad rush to download, please be cognizant that this is code in its crudest form. I'll update the sample as the tool proceeds through its stabilization phase. In the meantime, feel free to get in touch with me if there are any questions. Enjoy.

The transcripts for the MSDN Designing .NET Class Libraries class that Brad Abrams coordinated a few months back have finally been posted.

Amir Khella shows how easy it is to create stunning visual effects in Avalon in his Playing Around with Avalon's Grid entry. Amazing!

I'm working on finishing up the code for the next release of ColorPicker.NET. The main focus of this release is on incorporating the screen pixel sampling functionality that so many people have requested. While working on the design, I decided that I wanted the user to do all of the color sampling from within the tool. This means that instead of being able to extend the cursor outside of the tool's boundaries to sample colors, you need to select the desired screen area using the available functionality and do all of the zooming and sampling inside the tool. The result can be seen in the following screenshot.

The screen capture panel on the left side represents the area of the desktop that the user has selected. You can capture your preferred area by scrolling using the hot spots on the edges of the panel or by holding down the control key, clicking on the screen capture panel and dragging the translucent rectangle around the screen. As you drag, the area under the location of this rectangle will be displayed in the screen capture panel.

Once you have captured the desired screen area, you will need to make a more specific selection. Do this by clicking inside the screen capture panel. This will activate what I call a zoom rectangle. This defaults to a zoom power of 1x. If you would like to zoom in further, select the desired zoom power from the magnifier control. Once you have zoomed in on the captured image, you can sample colors by clicking (and moving) within the bounds of the zoomed image panel on the upper right side of the control.

As I mentioned earlier, I'm still working on finishing up, but I'd like some constructive criticism on the current implementation. Download the binaries and let me know what you think!