The delegate is for use when loading off of a thread to prevent a corss thread violation. You're right, it won't do much for speed if you are loading off the main thread .

Guys,

If you ever do an example for populating a listview off a thread, that would be great.

I have discovered that the it is not good practice to place a seektoprimary key, on a large table in a rowpopulating event. (I heard the sound of Doh!).

Other than that, I tried to do what you said, using a delegate to populate the listview but I just couldn't see what the eventual benefit was going to be, given that any population of the LV has to be done off its creating thread, so surely there is little if any benefit from doing this?

Given the work spent over the last 24 hours, got the form load time down from over 30 seconds to 4. So, it was worth the exercise.

thanks

G.

Not without creating one...but you will have to use a delegate to prevent a cross-thread violation.  The first thing I would be curios of when tackling a problem like this is where the bottleneck actually is....what line of code, etc.  I would recommend using a profiler like Ants or AQTime to see where your bottleneck is so that you can go after it in a more structured manner.  This is generally what we will do.

Trent,

This was where I started first. The query seems to come back absolutely lightning. If I trace through, the big pause comes on listview.requery.

this is the proc

CREATE PROCEDURE [dbo].[Customer_SEL_All_List] AS Select ID, CustomerName, Address1, County, Postcode, CustomerType, CustomerReference, Switchboard, CreditLimit, CurrentBalance from Customer

I kind of wondered if my rowpopulating event was having a major hit, but it doesn't seem to be. So, it's something else I am not doing or am doing wrong.

I would really prefer not to use virtualmode, as I see it as moving away from the SF benefits.

Intrigued to know how to fill the LV on a thread through. You got an example?

best regards

Geoff Hirst

If you are going to use a virtual mode you will have to manually load the ListView.  But whether you use Virtual Mode or not, you can still load on a thread.

To be honest, this may be one place that you just want to throw in the towel and use a DataGrid instead of a ListView.  But here is the first thing that you need to get working fast....the query!  If you can get your query to less than a secnd, then you can get the grid/ListView to load in another 1-2 seconds.  I am speaking from vast experience on this very topic.  We have several places in our medical software where we have to bring back all of a patients historical transactions, etc.  There are some cases that this may include 6000-10000 records.  We have this retrieved, populated, and ready for viewing in around 1.5 seconds...and this includes using very complex banding, etc.  So the first place to focus will be the query and then you can go from there.

Guys,

I have my main form in my application and it may contain up to 4 listviews. When I say may, I am using the devexpress layout control and the user may customize the form and remove any/all of the listviews if they are not relevant for their usage.

Now one of the listviews takes the most time to populate. At around 19 seconds for the whole form to load, I can't say I am happy with it. I have done a heap of stuff refining what is returned from the DB and also used Beginupdate and Endupdate and this has made some difference I have gained about 8 seconds off the original start-up time.

My rowpopulating event has some relatively simple coding in there to test values and display in a different colour where necessary.

Now, I am loading around 8000 items, which yes, is a lot (but some msdn guys are loading tens of 000's) and they may not be used, so I would like to look at the possibility of using VirtualMode or maybe do you have a paging method for the listview?

Ideally, I would like to be able to load the listview off a background thread, but I think I know where that would lead.

Ideas appreciated.

Thanks in advance

Geoff Hirst