Function LV_GeneralSort

source/script_gui.cpp:10645–10738

int CALLBACK LV_GeneralSort(LPARAM lParam1, LPARAM lParam2, LPARAM lParamSort)
// ListView sorting by field's text or something derived from the text for each call.
{
	LV_SortType &lvs = *(LV_SortType *)lParamSort;

	// v1.0.44.12: Testing shows that LVM_GETITEMW automatically converts the ANSI contents of our ListView
	// into Unicode, which is nice because it avoids the overhead and code size of having to call
	// ToWideChar(), along with the extra/temp buffers it requires to receive the wide version.
	UINT msg_lvm_getitem = (lvs.col.case_sensitive == SCS_INSENSITIVE_LOGICAL && lvs.col.type == LV_COL_TEXT)
		? LVM_GETITEMW : LVM_GETITEM; // Both items above are checked so that SCS_INSENSITIVE_LOGICAL can be effect even for non-text columns because it allows a column to be later changed to TEXT and retain its "logical-sort" setting.
	// NOTE: It's safe to send a LVITEM struct rather than an LVITEMW with the LVM_GETITEMW message because
	// the only difference between them is the type "LPWSTR pszText", which is no problem as long as caller
	// has properly halved cchTextMax to reflect that wide-chars are twice as wide as 8-bit characters.

	// MSDN: "During the sorting process, the list-view contents are unstable. If the [ListView_SortItems]
	// callback function sends any messages to the list-view control, the results are unpredictable (aside
	// from LVM_GETITEM, which is allowed by ListView_SortItemsEx but not ListView_SortItems)."
	// Since SortItemsEx has become so much more common/available, the doubt about whether the non-Ex
	// ListView_SortItems actually allows LVM_GETITEM (which it probably does in spite of not being
	// documented) much less of a concern.
	// Older: It seems hard to believe that you shouldn't send ANY kind of message because how could you
	// ever use ListView_SortItems() without either having LVS_OWNERDATA or allocating temp memory for the
	// entire column (to whose rows lParam would point)?
	// UPDATE: The following seems to be one alternative:
	// Do a "virtual qsort" on this column's contents by having qsort() sort an array of row numbers according
	// to the contents of each particular row's field in that column (i.e. qsort's callback would call LV_GETITEM).
	// In other words, the array would start off in order (1,2,3) but afterward would contain the proper sort
	// (e.g. 3,1,2). Next, traverse the array and store the correct "order number" in the corresponding row's
	// special "lParam container" (for example, 3,1,2 would store 1 in row 3, 2 in row 1, and 3 in row 2, and 4 in...).
	// Then the ListView can be sorted via a method like the high performance LV_Int32Sort.
	// However, since the above would require TWO SORTS, it would probably be slower (though the second sort would
	// require only a tiny fraction of the time of the first).
	lvs.lvi.pszText = lvs.buf1; // lvi's other members were already set by the caller.
	if (lvs.incoming_is_index) // Serves to avoid the potentially high performance overhead of ListView_FindItem() where possible.
	{
		lvs.lvi.iItem = (int)lParam1;
		SendMessage(lvs.hwnd, msg_lvm_getitem, 0, (LPARAM)&lvs.lvi); // Use LVM_GETITEM vs. LVM_GETITEMTEXT because MSDN says that only LVM_GETITEM is safe during the sort.
	}
	else
	{
		// Unfortunately, lParam cannot be used as the index itself because apparently, the sorting
		// process puts the item indices into a state of flux.  In other words, the indices are
		// changing while the sort progresses, so it's not possible to use an item's original index
		// as a way to uniquely identify it.
		lvs.lvfi.lParam = lParam1;
		lvs.lvi.iItem = ListView_FindItem(lvs.hwnd, -1, &lvs.lvfi);
		if (lvs.lvi.iItem < 0) // Not found.  Impossible if caller set the LParam to a unique value.
			*lvs.buf1 = '\0';
		else
			SendMessage(lvs.hwnd, msg_lvm_getitem, 0, (LPARAM)&lvs.lvi);
	}

	// Must use lvi.pszText vs. buf because MSDN says (for LVM_GETITEM, but it might also apply to
	// LVM_GETITEMTEXT even though it isn't documented): "Applications should not assume that the text will
	// necessarily be placed in the specified buffer. The control may instead change the pszText member
	// of the structure to point to the new text rather than place it in the buffer."
	LPTSTR field1 = lvs.lvi.pszText; // Save value of pszText in case it no longer points to lvs.buf1.