Time-consuming ListView adding

[Kadett]

Hi all, I have following problem: I'm creating a ListView (Details) control
at run-time and filling it with some records (let's say 10 000). This
operation seems to be quite fast, but when I call Controls[x].Add(list),
where list is my ListView control, then program hangs for minute. It seems
like this time depends on number of records added to control. So probably
when adding control to my form, those records are actualy added at this time
(not when calling ListView.Items.Add)... However, does anybody know the way
how to avoid this hanging ? I've tried to put all records adding loop to
background worker, but it gave no effects as they are really added when
adding control to the form. Help.Thanks.

[Michael A. Covington]

Are you doing listView1.BeginUpdate() before doing the massive add and
EndUpdate() afterward? That should speed it up by telling it not to update
the screen every time you add a data item.

"Kadett" <ka****@cons.plwrote in message
news:OH**************@TK2MSFTNGP02.phx.gbl...

Hi all, I have following problem: I'm creating a ListView (Details)
control at run-time and filling it with some records (let's say 10 000).
This operation seems to be quite fast, but when I call
Controls[x].Add(list), where list is my ListView control, then program
hangs for minute. It seems like this time depends on number of records
added to control. So probably when adding control to my form, those
records are actualy added at this time (not when calling
ListView.Items.Add)... However, does anybody know the way how to avoid
this hanging ? I've tried to put all records adding loop to background
worker, but it gave no effects as they are really added when adding
control to the form. Help.Thanks.

[Stephany Young]

I'm not sure that is an issue. My reading of the OP is that the
ListViewItems are being added to the ListView before the ListView is added
to the Controls collection. Why one would do it that way escapes me as does
why one would want to add 10,000 items - the human brain just can't be able
to cope with that much information.

If the ListView was added to the Controls collection and then filled then
certainly use of the BeginUpdate and EndUpdate methods should be beneficial.

There are a lot of factors here, which we have been made privvy to, like how
much data there is in a single ListViewItem, how efficient is the code that
is creating each ListViewItem etc.

That said, in dealing with 10,000 ListViewItems, there is going to some sort
of bottleneck somewhere.

Perhaps the OP might like to post the PERTINENT code fragments.
"Michael A. Covington" <lo**@ai.uga.edu.for.addresswrote in message
news:OZ**************@TK2MSFTNGP04.phx.gbl...

Are you doing listView1.BeginUpdate() before doing the massive add and
EndUpdate() afterward? That should speed it up by telling it not to
update the screen every time you add a data item.

"Kadett" <ka****@cons.plwrote in message
news:OH**************@TK2MSFTNGP02.phx.gbl...

>Hi all, I have following problem: I'm creating a ListView (Details)
control at run-time and filling it with some records (let's say 10 000).
This operation seems to be quite fast, but when I call
Controls[x].Add(list), where list is my ListView control, then program
hangs for minute. It seems like this time depends on number of records
added to control. So probably when adding control to my form, those
records are actualy added at this time (not when calling
ListView.Items.Add)... However, does anybody know the way how to avoid
this hanging ? I've tried to put all records adding loop to background
worker, but it gave no effects as they are really added when adding
control to the form. Help.Thanks.

[Kevin Frey]

Sooner or later the .NET control will have to move its data into a Windows
Control. I am guessing that the delay you are experiencing is due to the
underlying windows control being populated from your list.

Have you tried adding the listbox to the form before you start adding items,
and using BeginUpdate/EndUpdate as the previous poster recommended. If the
control is clever (I have no idea) it might give you better run-time
behaviour (not necessarily faster, but you might be able to control it
better).

And, for what it's worth, a listview is entirely inappropriate for
presenting 10,000 items, despite it being capable of doing it. You probably
need a search facility.

"Kadett" <ka****@cons.plwrote in message
news:OH**************@TK2MSFTNGP02.phx.gbl...

Hi all, I have following problem: I'm creating a ListView (Details)
control at run-time and filling it with some records (let's say 10 000).
This operation seems to be quite fast, but when I call
Controls[x].Add(list), where list is my ListView control, then program
hangs for minute. It seems like this time depends on number of records
added to control. So probably when adding control to my form, those
records are actualy added at this time (not when calling
ListView.Items.Add)... However, does anybody know the way how to avoid
this hanging ? I've tried to put all records adding loop to background
worker, but it gave no effects as they are really added when adding
control to the form. Help.Thanks.

[Michael A. Covington]

"Stephany Young" <noone@localhostwrote in message
news:uG**************@TK2MSFTNGP05.phx.gbl...

I'm not sure that is an issue. My reading of the OP is that the
ListViewItems are being added to the ListView before the ListView is added
to the Controls collection. Why one would do it that way escapes me as
does why one would want to add 10,000 items - the human brain just can't
be able to cope with that much information.

Yes. I wonder what it is like to use a ListView with 10,000 items in it.
It may be well beyond some practical size limit that the implementors had in
mind.

[Kadett]

I'm not sure that is an issue. My reading of the OP is that the
ListViewItems are being added to the ListView before the ListView is added
to the Controls collection.

That's right. We read some data from particular file and show them in
table-like form. We don't know how many records there will be, as we don't
know how big is source file... However - of course there's possibility of
putting data to the contorl in parts. But it means creating some new methods
just for handling user events (key down, move slider, etc). Yes, maybe I'm
lazy, I did it while programming in VC++, but I've hoped C# would do this
for me :) Anyway thank you for any suggestions, they are precious as always.

[Stephany Young]

Instead of a listview, you might consider inserting the data into a
DataTable and then binding that DataTbale to a DataGridView. A DataGridView
is designed for that sort of thing.
"Kadett" <ka****@cons.plwrote in message
news:OK**************@TK2MSFTNGP05.phx.gbl...

>

>I'm not sure that is an issue. My reading of the OP is that the
ListViewItems are being added to the ListView before the ListView is
added to the Controls collection.

That's right. We read some data from particular file and show them in
table-like form. We don't know how many records there will be, as we don't
know how big is source file... However - of course there's possibility of
putting data to the contorl in parts. But it means creating some new
methods just for handling user events (key down, move slider, etc). Yes,
maybe I'm lazy, I did it while programming in VC++, but I've hoped C#
would do this for me :) Anyway thank you for any suggestions, they are
precious as always.

[Kadett]

U¿ytkownik "Kevin Frey" <ke**********@hotmail.comnapisa³ w wiadomo¶ci
news:ez**************@TK2MSFTNGP06.phx.gbl...

Have you tried adding the listbox to the form before you start adding
items, and using BeginUpdate/EndUpdate as the previous poster recommended.
If the control is clever (I have no idea) it might give you better
run-time behaviour (not necessarily faster, but you might be able to
control it better).

That is some idea - it probably won't be faster but I can try to display
some progress information meanwhile...

>
And, for what it's worth, a listview is entirely inappropriate for
presenting 10,000 items, despite it being capable of doing it. You
probably need a search facility.

Ye, I know that - but this is forensic software so I have to display alll
the information I can provide. If user will want to get some choosen part -
then he can do some filter/search operation, but at the start he need to
have all the records...

Thank you.

[Bruce Wood]

Peter wrote:

I'd still recommend that you employ some sort of select filter at the
beginning, such as get all the items starting with "A", or "H", etc. Surely
the user has some idea which part of the data they will want to look through
at the beginning?
10,000 rows in a listView or in any other control is overkill.
Peter

Now I'm interested, as we do exactly the same thing... with about
50,000 items.

Our situation is that this is a pick list: the user chooses which item
they want to work with. We use a list view because we want to display
two or three pieces of information about each item: stock code and a
couple of item descriptions.

We created a search (text) box below that allows the user to type a
partial stock code and the list view seeks to the first code starting
with the letters they have typed. When they find the entry they want,
they click on it and this populates a detail screen with information.

And yes, it takes a long time to populate the list view.

The problem is how to provide the user with a reasonable way to choose
from amongst 50,000 items without creating some hokey interface that
requires a lot of interaction.

And no, in this case a search facility is inappropriate because they're
not searching on attributes, they're searching on a code. Populating
the list view as they type the code was also problematic, as in my
earlier experiments the round trips to the database as they typed each
character were just too slow.

[Peter Bromberg [C# MVP]]

What I was suggesting was more of a Typeahead / AutosuggestBox type of
arrangment where the first say, 2 or 3 letters typed into the search Textbox
(using say the Keyup event) cause a call to the (database) with those letters
comprising a SQL WHERE CLAUSE -- WHERE XYZ LIKE 'abc%'
which would return a much more manageable subset that immediately populates
the ListView (or whatever display control it is).
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Bruce Wood" wrote:

>
Peter wrote:

I'd still recommend that you employ some sort of select filter at the
beginning, such as get all the items starting with "A", or "H", etc. Surely
the user has some idea which part of the data they will want to look through
at the beginning?
10,000 rows in a listView or in any other control is overkill.
Peter

Now I'm interested, as we do exactly the same thing... with about
50,000 items.

Our situation is that this is a pick list: the user chooses which item
they want to work with. We use a list view because we want to display
two or three pieces of information about each item: stock code and a
couple of item descriptions.

We created a search (text) box below that allows the user to type a
partial stock code and the list view seeks to the first code starting
with the letters they have typed. When they find the entry they want,
they click on it and this populates a detail screen with information.

And yes, it takes a long time to populate the list view.

The problem is how to provide the user with a reasonable way to choose
from amongst 50,000 items without creating some hokey interface that
requires a lot of interaction.

And no, in this case a search facility is inappropriate because they're
not searching on attributes, they're searching on a code. Populating
the list view as they type the code was also problematic, as in my
earlier experiments the round trips to the database as they typed each
character were just too slow.