[Xman1]

because of this code

void CDownloadClientsCtrl::RefreshClient(CUpDownClient* client)
{
	if( !theApp.emuledlg->IsRunning() )
  return;
	
	//MORPH START - SiRoB, Don't Refresh item if not needed 
	if( theApp.emuledlg->activewnd != theApp.emuledlg->transferwnd  || theApp.emuledlg->transferwnd->downloadclientsctrl.IsWindowVisible() == false ) 
  return; 
	//MORPH END   - SiRoB, Don't Refresh item if not needed 

the list isn't beeing sorted correctly when it is(/was) hidden.

Fix:

Quote

void CDownloadClientsCtrl::AddClient(CUpDownClient* client)
{
if(!theApp.emuledlg->IsRunning())
  return;
      
//Xman Sorting Fix
int iItem = InsertItem(LVIF_TEXT|LVIF_PARAM, GetItemCount(), client->GetUserName(), 0, 0, 1, (LPARAM)client);
Update(iItem);
//InsertItem(LVIF_TEXT|LVIF_PARAM, GetItemCount(), client->GetUserName(), 0, 0, 1, (LPARAM)client);
//RefreshClient(client);
//Xman end
theApp.emuledlg->transferwnd->UpdateListCount(CTransferWnd::wnd2Downloading, GetItemCount());
}

This post has been edited by Xman1: 22 October 2005 - 08:50 AM

[SlugFiller]

And what happens if a client's info is changed while the list isn't visible?
Also, does this actually matter? Wouldn't it be resorted when it is made visible?
If not, shouldn't that little optimization in RefreshClient be removed altogether?

[Xman1]

@SlugFiller
good questions.. I thought you (the sorting expert) can give me the answers.

Ok.. what I found out is following:
- when the list become visible and an update (redrawing) occur and you sorted by a value which change (e.g. downloadspeed) it will be resorted.
- when the list become visible and an update (redrawing) occur and you sorted by a value which doesn't change (e.g. filename) it will not be resorted.
Because of the second one, you need at least one initial-sorting, which is now done.
After this first sorting, you can use morphs patch. It works now, because the items of this list are updated every x seconds and if sorted by a changing value, it will be resorted.

This post has been edited by Xman1: 22 October 2005 - 02:00 PM

[SlugFiller]

But the filename can change if you are A4AF. The whole optimization there seems unsafe, and it's not present in any of the other lists. Perhaps it's best to not have it at all.
How much would that cost, in terms of CPU power?

[Xman1]

I have this optimization in every list... and it works except at the clientslistctrl, where I sort now when the window become visible.
My profiler told me, that drawing of progressbar needs many time. Most time need the FillRect(). Therefore the morph-optimization is a good thing.

And remark: the filename can't change because of A4AF at downloadclientsctrl (at least not with official client, but with Xtreme)

[SlugFiller]

Quote

My profiler told me, that drawing of progressbar needs many time. Most time need the FillRect(). Therefore the morph-optimization is a good thing.

Maybe there's a way to modify RefreshClient so that it still sorts if it doesn't redraw.
The alternative is to alter the drawing function to check it's visibility state. That would be helpful for all lists.

[SiRoB]

SlugFiller, on Oct 22 2005, 06:40 PM, said:

The alternative is to alter the drawing function to check it's visibility state. That would be helpful for all lists.

Well i already made this, called "don't draw hidden rect", some age ago.
Basicly this make column or row hidden to not be drawn.

I made this change ("don't refresh item if not needed") because there is many find into list that would rise the cpu consumption for nothing.

Quote

LVFINDINFO find;
find.flags = LVFI_PARAM;
find.lParam = (LPARAM)client;
sint16 result = FindItem(&find);
if(result != -1)
  Update(result);

I admit that my way is a little bit hard,
but for sur in all the refresh call i definitly don't waste cpu time.

SlugFiller, on Oct 22 2005, 03:08 PM, said:

And what happens if a client's info is changed while the list isn't visible?
Also, does this actually matter? Wouldn't it be resorted when it is made visible?
If not, shouldn't that little optimization in RefreshClient be removed altogether?

Arround the delay of the information,
well i wonder if item are drawn again when the list is visible again?
If yes i don't care if don't see the porper information for tiny time vs saved cpu time.

Thank's for the sorting fix Xman1.

P.S.: i guess this fix should not be there.

[SlugFiller]

Quote

sint16 result = FindItem(&find);

Hmm... If this has a high CPU cost, there has to be a better way.
Maybe a map?
Or would there be issues with item removal, resorting, or whatever?