What is the opposite of LVM_SORTITEMS?
A customer was using the LVM_SORTÂITEMS message to sort the items in a classic Win32 ListView control in response to the user checking a box called “Show sorted by date”.
That part worked great.
They ran into trouble when the user unchecked the box: What is the message for telling the ListView control to return to what it looked like before it was sorted?
There is no such message.
Sorting a ListView is a destructive operation. The items are sorted according to the new criteria, and the previous item order is lost. You’ll have to restore the order yourself. For example, if the ListView had been sorted by name before the user chose to sort by date, you can return to the previous order by re-sorting by name. On the other hand, if there was no particular order to the items, you’ll have to save the original order and reapply it when the box is unchecked.
If you think about it, there’s no way the ListView could confidently restore the previous order: Suppose that after sorting by date, the user creates a new item, and then unchecks the box. Even if the ListView had remembered the previous item order, it wouldn’t know where to put that new item. (Maybe the customer expected the “undo sort” to be a roll-back and also delete the newly-added item?)
If you want things back the way they were, you’ll have to remember where they were.
Bonus chatter: In Windows 2000, you used to be allowed to pass nullptr as the sort callback function for LVM_SORTÂITEMS, and it would default to sorting alphabetically by the first column. If you tried that in Windows XP, however, you got an “invalid parameter” error. This was a regression introduced by the Windows security push and some overzealous parameter validation. Surprisingly, nobody noticed this regression for several years, by which point the new stricter validation had become accepted as the new standard behavior. It was a bug with seniority.
Light
Dark
3 comments
Off-topic, but just to say thanks for your blog post from 11 years ago, which was really helpful to me today: Reading the output of a command into a batch file variable.
I consider myself a seasoned programmer, yet I’ve caught myself wishing to “unring the bell” on occasion. A silly notion of course, for the reasons you mentioned, but it shows how disconnected from reality/intuition UIs can be sometimes.
The only real solution would be to implement some sort of version control on UI operations, so the user could rollback the sorting and then merge manually the new additions. Imagine the support tickets…
Personally, I would add the original sort sequence to the lParam for each item in the list. Then it would be easy to restore by “sorting” on the original item order. It isn’t built-in (though one more integer probably wouldn’t blow anyone’s memory away) so as so often happens, that part of the code is left out of the control and made the customer’s (in this case, the programmer using the control) responsibility, and every programmer will find a different way to solve it, each with their own (potential) bugs. At least it keeps things interesting. 🙂