Adding millions of rows to a UI control without locking up the UI?

[Danny Tuppeny]

Hi all,

Something bugs me. It's the whole "not accessing a control from a non-UI
thread" thing...

In my world, all properties would be safe from all threads (maybe they'd be
locked internally?), and paint methods/events would automatically be
marshalled into the UI thread.

It seems this isn't the case (I'm sure there are reasons, but I don't know
what they are), and code that affects the UI must be done in the UI thread.
So, my question is, how do I add millions of rows to a listbox? Take the
code below for example:

DataTable dt = ((DataSet)e.Result).Tables[0];
listCategories.Items.BeginUpdate();
listCategories.Items.Clear();
foreach (DataRow dr in dt.Rows)
{
listCategories.Items.Add(dr["CategoryName"]);
}
listCategories.Items.EndUpdate();

What's the solution if I have millions of rows? Calling DoEvents within the
loop slows things down *massively*, and calling it every x rows is messy.

I'm guessing I could set Visible to false, add all my rows in a background
hread, and then set visible to true, but that looks awful.

Then, maybe BeginUpdate/EndUpdate means I can add items on a background
thread? I don't know.

I'm just curious. In the past, I've had to do processing that was lengthy to
make the UI sluggish, but was updating the UI in a loop, making seperating
the UI-writing and the processing almost impossible.

What's the usual way of doing this kind of thing?

Thanks,

 

[Joanna Carter [TeamB]]

"Danny Tuppeny" <[email protected]> a écrit dans le message de
[email protected]...

| So, my question is, how do I add millions of rows to a listbox? Take the
| code below for example:

My first question to you is, what user actually wants to browse millions of
rows ????

Surely your users must know something about the items that they are looking
for; you can always set up a search dialog or integrate it into a form that
shows the list.

However, if you insist on displaying that kind of quantity of rows, then you
should use the virtual mode of a control, feeding the records on an 'as
required' basis. Just don't expect the scrollbar to be proportional to the
number of rows, just set the scroll range to three and manage it so that it
is always in the middle except when you reach one of the ends.

Your better choice is to avoid such atrocities as showing so many rows

Joanna

 

[Danny Tuppeny]

"Danny Tuppeny" <[email protected]> a écrit dans le message de
[email protected]...

| So, my question is, how do I add millions of rows to a listbox? Take the
| code below for example:

My first question to you is, what user actually wants to browse millions
of
rows ????

Surely your users must know something about the items that they are
looking
for; you can always set up a search dialog or integrate it into a form
that
shows the list.

However, if you insist on displaying that kind of quantity of rows, then
you
should use the virtual mode of a control, feeding the records on an 'as
required' basis. Just don't expect the scrollbar to be proportional to the
number of rows, just set the scroll range to three and manage it so that
it
is always in the middle except when you reach one of the ends.

Your better choice is to avoid such atrocities as showing so many rows

Sorry, I wasn't clear enough. I'm not doing something this stupid - I'm
being curious

I've come across situations where I've only needed tens of rows, but there
was a tiny amount of processing in there, which slowed the UI down. A
solution to the above problem would also be a solution to that problem!

I can't think of exactly what I was doing to have a similar problem, but I'm
sure it must be common - needing to use the UI thread, but having something
that takes longer than the user would like to see the UI lock up for!

Danny

 

[Chris R. Timmons]

Hi all,

Something bugs me. It's the whole "not accessing a control from
a non-UI thread" thing...

<snip>

It seems this isn't the case (I'm sure there are reasons, but I
don't know what they are), and code that affects the UI must be
done in the UI thread.

Danny,

You can access UI elements from w/i a non-UI thread. The requirement
is that the non-UI thread has to be launched from the main UI thread.
See the documentation for System.Windows.Forms.Form.BeginInvoke.