>Ed,
>
>One comment-
>
>While I agree with most of what you said, I think we need to provide this information to the user in some form. How many times have you clicked twice on the name header of WinExplorer to make sure it it was sorted and in the right order while looking for a file?
>

If you read further in my reply, for our own use in-house at Weatherhill, we use a standard of prefixing the caption in the header with « or » and changing the font between italic and non-italic to indicate the sort. It's visually much more effective and intuitive than underline to determine direction of sort for my users, and is no more difficult to implement than setting the FontUnderline property. The choice worked in-house quite well. If we had to, we'd use a font that had uparrow and downarrow symbols in it. We probably would not go in the direction of adding a complex graphical construct that would inhibit the resizing or repositioning of grid elements.

>In my opinion, if one column is different than another there needs to be an indicator that shows this. It does not have to be an icon showing the direction of the sort order. Maybe a simple thing like .FontBold= .T. on the header showing the column is sorted.
>
>Also, the other day I was working on a large table sorted by last name and I had to goto the 4th character to determine the sort order (challengeing for the user). This is when I decided to add .FontUnderline= .T. for descending order.
>
>This solution is not pretty but it was VERY simple to implement AND requires little maintenance. I don't expect that I will settle with this in the long run but it moves me forward in my project...
>

If it works for you in your applications, great! As I said, we have a similar standard, switching the column header FontItalic property and altering the caption. The important thing here is that we have a standard that satisfies our users.

There are plenty of circumstances where a change in the font characterisitic would not be acceptable for more than eyecandy reasons. One that comes to mind immediately is in situations with visually-impaired users; something I've had to deal with for clients in the past. In this situation, a change in the reported text in the header is vital, since many screenreaders don't make an easy distinction when the font emphasis, or even the font itself, is altered. A clear trigger that makes itself readily observed and reportable to the user is of critical importance; something that is obvious to the normal user may be completely worthless in this situation. In fact, it's sometimes necessary to make the change 'visisble' in the data elements of the columns, since the user may not be able to see the column header at all!

The entire intent of my entry into this conversation, which I'm regretting at the moment, was to suggest that an alternative that was similar visually to the desired result, and was both much easier to implement and was far more maintainable than the various kludges available to get the "disabled graphical arrowhead", was available and worth considering.