ListView Control Hangs during Sort

[Stoic Joker]

Greetings
  I seem to recall seeing the answer for this once before, I just can't remember where... *Sigh*

  Anyhow, I have an app I'm working on (suite of them actually) that display's data which is queried from a MySQL db. It's written (as usual for me) in straight Win32 API C++ (No .Net/MFC/etc.). The issue I'm having is that when the list box control is sorted by the (14th) Cost column the ListView control locks up untill the app is restarted.

  Now in the various columns I do switch between alphabetical & numeric sorting, which works just fine for the first 11 columns, but... 12 & 13 only sort one direction instead of toggling between asc & desc, and 14 just hangs the LV thread completely. I've been using the same ListView Sort code in several different apps that all work just fine, but have 10 colums or less.

  Which brings me to (the point?) my question. Does anybody recall seeing an issue with (and solution for) ListView controls having more than X number of columns hanging during sort? I swear I've seen this before reguarding a bugg in the LV control ... I just can't remember where or what the solution was.

I'm using MSVS 2005 SP1

Thank You

[mouser]

how many rows of data?

[f0dder]

Never heard of such a bug (but not saying it can't exist ).

How do you manage the items? virtual mode, or letting the control manage strings internally?

[Stoic Joker]

how many rows of data?

Doesn't matter be it 3 or 300 (Most I ever tried was 2000) behavior is the same.

Never heard of such a bug (but not saying it can't exist ).

How do you manage the items? virtual mode, or letting the control manage strings internally?

If I'm understanding the question correctly, the control is managing internally. I'm not doing anything OwnerDrawn/Clever it's just a fairly straight forward ListView_InsertColumn(...) ListView_InsertItem(...) sort of affair.

This is basically the sort code I'm using (from an older 7 column version of the app):

Code: (cpp)

#include "stdafx.h"

extern HWND g_hListBox;
extern int nSortDir[7];

int CALLBACK ListViewCompareProc(LPARAM lParam1, LPARAM lParam2, LPARAM lParamSort) {
	static char szBuf1[100], szBuf2[100];
	int i1, i2;

   //=================================== Retrieve the item text so we can compare it.
  ListView_GetItemText(g_hListBox, lParam1, (int)lParamSort, szBuf1, sizeof(szBuf1));
  ListView_GetItemText(g_hListBox, lParam2, (int)lParamSort, szBuf2, sizeof(szBuf2));
  //============================================= Then Return the Comparison Results.
  if(lParamSort >= 5) { //================= Sort PageCount Columns 5 & 6 as a Number.
     i1 = strtol(szBuf1, 0, 10);
	 i2 = strtol(szBuf2, 0, 10);
     if(nSortDir[lParamSort]) //========= Toggle Between ASCENDING & DESCENDING ORDER
	    return i1-i2; //====================================== Sort Order ASCENDING
	 else
	    return i1+i2; //===================================== Sort Order DESCENDING
   }else{ //========================= Sort ALL the Rest (Alphabetically) as a String.
	 if(nSortDir[lParamSort]) //========= Toggle Between ASCENDING & DESCENDING ORDER
		return(_stricmp(szBuf1, szBuf2) * -1); //=============== Sort Order ASCENDING
	 else
		return(_stricmp(szBuf1, szBuf2)); //=================== Sort Order DESCENDING
  }
}

It was probably 2 years ago when I saw the bugg discussion ... thinking that I'd never need to use that many columns I ignored it and moved on to other more (at the time) relevant issues. Now I'm racking my brain trying to remember where I'd seen it because (several columns later) the bugg is now gnawing my ass off

[Eóin]

A ListView will hang if the CompareProc returns inconsistent results, eg a < b < c but c < a.

In the code posted there seems to be a logic error in line 20, really seems like it should be return i2-i1;

[Stoic Joker]

A ListView will hang if the CompareProc returns inconsistent results, eg a < b < c but c < a.

In the code posted there seems to be a logic error in line 20, really seems like it should be return i2-i1;

Hm... wouldn't that then have to fail consistently for all (numerically sorted) columns? In the program (with the issue) half the columns are sorted numerically and half are sorted alphabetically. Out of the numerically sorted columns there are IP Addresses, (alpha-numeric) serial numbers, and some actual real live plain old numbers ranging from (roughly) -185,456 - 1,456,789 all of which sort just fine ... unless they are in column 14 (13 if you count from 0 - the control does). It just doesn't track that a logic bugg would be that forgiving.

*Shrug*

I'll put that on my todo list and try it in the morning when I get to the office (I'd certainly love a simple answer), but it just doesn't feel right...Perhaps because I'm mentally stuck (or just mental) on the column count bugg.

[mouser]

i think Eoin may have nailed it.

[Stoic Joker]

i think Eoin may have nailed it.

Sorry No Joy.

I decided to remote into the office & try it (the suspense was killing me...). ...I'll give you this much, the sort is a bit smoother. But it still locks up on column 14.

Just to make sure nothing was being missed, I commented out all of the numeric sort code so everything had to be sorted alphabetically. 1-13 = perfect ... 14 = ListView Control hang/frozen solid.

[mouser]

nSortDir[7]; <--- only goes up to index 0-6 and yet you are sorting on column 14?

[Stoic Joker]

It's an old code sample, the actual project is nSortDir[14];

Strangely (Since I'd been missing that seemingly key point) Id left the original nSortDir[7] in the project while User Requests caused columns to be added and it never caused a problem until adding the last 14th column. I've still got a 13 column version of the program using nSortDir[7] that works just fine (Damn strange in retrospect). That was the first thing I tried when the bugg was discovered.

Just for clarity (Now that I'm logged into the office), here is the most current version of the broken code :

Code: (cpp)

#include "stdafx.h"

extern HWND g_hListBox;

int CALLBACK ListViewCompareProc(LPARAM lParam1, LPARAM lParam2, LPARAM lParamSort) {
	static char szBuf1[100], szBuf2[100];
	extern int nSortDir[14];//[7];
	int i1, i2;

   //=================================== Retrieve the item text so we can compare it.
  ListView_GetItemText(g_hListBox, lParam1, (int)lParamSort, szBuf1, sizeof(szBuf1));
  ListView_GetItemText(g_hListBox, lParam2, (int)lParamSort, szBuf2, sizeof(szBuf2));
  //============================================= Then Return the Comparison Results.
  if((lParamSort == 5)||(lParamSort >= 7)) { // Sort Only PageCount Columns 5 and 7
     i1 = strtol(szBuf1, 0, 10);  //-+++--> & up as a Number. Columns 4 & below and
	 i2 = strtol(szBuf2, 0, 10); //--+++--> 6 are Sorted as Words (alphabetically).
     if(nSortDir[lParamSort]) //========= Toggle Between ASCENDING & DESCENDING ORDER
	    return i1-i2; //====================================== Sort Order ASCENDING
	 else			  // Thanks Eóin - From DonationCoder.com
	    return i2-i1;// <--Good/Bad--> i1+i2; //============= Sort Order DESCENDING
   }else{ //========================= Sort ALL the Rest (Alphabetically) as a String.
	 if(nSortDir[lParamSort]) //========= Toggle Between ASCENDING & DESCENDING ORDER
		return(_stricmp(szBuf1, szBuf2) * -1); //=============== Sort Order ASCENDING
	 else
		return(_stricmp(szBuf1, szBuf2)); //=================== Sort Order DESCENDING
  }
}

// Check to see if Alpha or Num Sort Locks up more/less/same
/* Note: This resolved a tendence to periodically sort things incorrectly
Eóin Re: ListView Control Hangs during Sort 
« Reply #4 on: 10/7/2009 at 04:49:47 PM » 
-------------------------------------------

A ListView will hang if the CompareProc returns 
inconsistent results, eg a < b < c but c < a.

In the code posted there seems to be a logic error 
in line 20, really seems like it should be return i2-i1;
*/

[Stoic Joker]

Okay it looks like the win goes to mouser for his Captain Obvious tip. it seems that the correct (or at least currently working) version is:
extern int nSortDir[]; with no size specified. Which allows the other locally declared reference (int nSirtDir[14]) to define the actual size.

Well... that and if the size is specified in both places...it apparently helps if they both :)ing match...

Thanks to all

[mouser]

real credit goes to Eoin for guessing the core problem, which was that the delay was the result of the callback returning inconsistent comparison results.  after that it was just a matter of figuring out why that was happening.

[Stoic Joker]

real credit goes to Eoin for guessing the core problem, which was that the delay was the result of the callback returning inconsistent comparison results.  after that it was just a matter of figuring out why that was happening.

Actually both i2-i1; and i1+i2; worked after the external array item you spotlighted was fixed. Something about that had always bothered me...just not enough to poke it with a stick. At least not until you tipped the scale by drawing attention to something that was obvious, but was also hiding another not-so-obvious boo-boo on my part. (Hint: the local definition of the array that the external reference was pointing to, was neither 7 nor 14 ...  )

Eóin's tip resolved an entirely different global issue, which was a tendency for the numerically sorted columns to be periodically sorted incorrectly. Which is why there is a comment to that effect in the source code I posted above. That comment will remain there in the official project file to remind me to never do that again.