The initial value of ColumnSortDirection seems to be Listbox.SortAscending. Why is this? Shouldn’t it be Listbox.SortNone?
Not in my opinion. When users click on a listbox header they generally expect it to sort so having the default as SortAscending simplifies the “normal” functionality. If you don’t want it to sort or want it to sort Descending, then you can specify it.
SortNone disables sorting altogether, so no, it should not be the default. There are 2 times when you would want to use ColumnSortDirection:
- Set it to SortNone so the user cannot click the column header and sort the column.
- Set it to Ascending/Descending just before you call Sort to sort it in code.
I’m not sure what the utility of reading the value would actually be.
Thanks. My fault - I understood this property completely wrong, and thought that the first click in the header of a column then would sort it in descending order. Which is nonsense of course (should have re-read the docs before asking).
Tim Hare writes: I’m not sure what the utility of reading the value {of ColumnSortDirection} would actually be.
This post helped me with a ListBox I am working with - and an answer to Tim’s question. I have a ListBox that is loaded from a DataBase; and after the database load - I foot the numeric columns … and add a “Last Row” to the Listbox that contains the “Totals”. The RowTag has the database PrimaryKey (for later updates) and in the “Last Row”, I put a marker in the RowTag identifying it as the “Totals” Row.
When the user clicks a header to sort - in CompareRows I check ColumnSortDirection to see if they are sorting the column in ASC or DES order - then return the CompareRows “result” such that the “Totals Row” is always considered the “Highest Row” (if ASC) and the “Lowest Row” (if DES). The user can sort any column - and the Totals Row is always at the bottom of the ListBox.
[quote=95985:@Tim Hare]SortNone disables sorting altogether, so no, it should not be the default. There are 2 times when you would want to use ColumnSortDirection:
…
I’m not sure what the utility of reading the value would actually be.[/quote]
Tim, here’s a scenario where reading SortDirection makes sense (albeit not necessarily good coding sense).
The customer wanted the date column to display in standard USA shortdate form but still wanted to be able to sort the dates. At the time (early REALBasic days) the easiest way was to have a hidden column containing the corresponding SQLDate. If the user clicked on the header of the visible date column, the app checked the sort direction of that column, reversed it and applied it to the SQLDate column and did the sort, reapplying the revised sort direction to the original visible column.
Not the cleanest way to do it but it worked (and has been replaced by better methods).
Steve’s scenario makes sense. Dale, you’re right, that’s no longer necessary.