Often a list view is used to perform multiple sorting by clicking consecutively on different fields, but the header does not maintain the sort order for multiple fields. After adding new records to the list the multiple sorting is not applied - only the current selected field.

The functionality should add to the existing familiarity in current header control design. Implementation would consist of a sort stack.

Left click on field:
- move field to top of stack
- toggle sort direction
- mark as a sort field

Double-click on field:
- move field to top of stack
- set sort direction ascending
- mark as sort field
- turn sorting flag off on all other fields

Each column can only appear once in the sort, so clicking on a column already in the stack reverses the order of sorting if it is the top of the stack or moves the column to the top of stack. Complex sort criteria can be maintained from the header.

I am currently at a loss as to how to display the sort order in the header. I have seen multiple arrows used, and entertained the idea of numbers in circles briefly.
Posted on 2004-02-22 21:16:29 by bitRAKE
Hi bitRAKE,

I was also playing with the idea of different kinds of sorting in a listview. My idea was to allow groupings, where you could group items in a listview and they would effectively be locked together during a sort. I had pretty much decided that the only way to indicate the groups would be to have the first column as a group indicator (probably a colored square or icon) and the header would be a lock/unlock button. Then when a sort column is selected each of the groups is independantly sorted and kept together. I have been working on it for a few days but currently have nothing to show but miserable failures for my efforts :)
Posted on 2004-02-22 23:11:11 by donkey
I recall doing something like this a while back - I used the ListView param as a pointer to a struct which contained the real item data as well as a tag indicating the group to which the item belonged. I used this in a debug tracer, to group different operators in a LV during tracetime, allowing fast identification of things like conditional branch opcodes.
Posted on 2004-02-22 23:30:11 by Homer
donkey, I was thinking maybe highlight the headers in a gradient color based on the sort order combined with an up/down arrow. :P It is not practical to use more than three columns for sorting - I've rarely needed more even when working with 100,000+ records. So, multiple up/down arrows might not be a bad thing either. I'm not quite sure how your grouping works -- I was thinking of sorting somthing like or . If your grouping works similarly then is the sort direction always ascending?

I was hoping to lazily sub-class the existing header control. :P
Posted on 2004-02-22 23:37:31 by bitRAKE
Hi bitRAKE,

Basically the grouping would be a flag that is common between like items. For example all management employees could be grouped and all warehouse, or there could be multiple groupings in an array pointer to by lParam and the sort criteria would specify which to use. My current idea is to have up to 4 groupings of 256 groups each so it will all fit a single DWORD. The different groups could be either user defined or application defined. When the LVM_SORTITEMSEX is sent the sorting proc would check the two items to see the group they belonged to, if they were the same it would sort based on the header selected field, if they were different it would sort based on the group. If the groupings were unlocked it would sort normally ignoring the groups all together. That was the original concept but for now it isn't giving me anything but a randomized list.
Posted on 2004-02-22 23:46:52 by donkey
donkey, cool idea to simplify sorting with a sacrifice in flexiblity. Unfortunately, I have a situation where only a few records are non-unique between sorting groups -- something like 30K records with 12K unique.
Posted on 2004-02-23 00:27:13 by bitRAKE
Hi bitRAKE,

Yeah, it would not work in a situation like that. My end goal is to also have the groupings collapsible where the top item would be displayed but the rest would be hidden until the group is opened. I had the idea that it might simplify the interface to my next project which is an install builder to compliment UpdateManager. I want to make a complete software publishing suite for web based distribution if possible. The engine is coming along slowly but I have not worked out the details of the UI. A treeview requires that too much information is not available on sight and has to be viewed and edited in child dialogs etc... A listview does not allow the same heirarchical structuring of the sections. If I don't give up, as I do too often, I will post the results.
Posted on 2004-02-23 00:35:21 by donkey