MVP please help - ShowDialog() very slow when child list box has many items

  • Thread starter Thread starter Valerie Hough
  • Start date Start date
V

Valerie Hough

Hi,

Development is done under XP SP2, C# .NET, Visual Studio .NET 2003, .NET
v1.1

I have a System.Windows.Form that displays a dialog when a button is
pressed.

The dialog has a list box, a text box used as a typing helper, and two
buttons in it.

The list box has approximately 50,000 items in it.

The first time the dialog is displayed it takes over 20 seconds, and even
subsequent calls to show it take almost as long (a mere 18-19 seconds), even
though the documentation says that any calls to ShowDialog() after the first
one are really only changing the visibility of the dialog.

In the Visual Studio debugger, it is the actual call to ShowDialog() that is
taking so long.

Task manager shows intense CPU activity during the 20 seconds, but little
memory activity.

With only a few thousand items there is no problem.

Once the dialog is displayed, I use a typing helper to scroll the list box
to different places; this all happens very quickly - no performance issues
at all once it is displayed.

Are there any callbacks that could be being invoked during ShowDialog() ?

Can anyone help?

Thanks in advance,
Chris Hough
 
The list box has approximately 50,000 items in it.
Can anyone help?
Click to expand...

Change your design - regardless of how long it takes for the dialog to
show up, having a listbox with 50'000 items in it is bad design. Make
it so that the user will get a list of a few hundred items at most -
anything beyond that is unmanageable for the users anyway. Then your
display times will be much quicker, too.

Marc
================================================================
Marc Scheuner May The Source Be With You!
Berne, Switzerland m.scheuner -at- inova.ch
 
Thanks for the programming lesson - how much do I owe you?

do not be sarcastic, Marc is right. what you should consider is to use
faster component, DataGrid for example, or redesign the view by showing to
the user several categories of items, for example on treeview with
dynamically expanable nodes.

your design is bad because even if you speed up things for 50000 items, what
will happen if there are 500000 items?

Wiktor Zychla
 
Marc was right, that's is a very bad design, try adding some previous
filtering to reduce the number of items in the list. Have you seen those web
pages with a series of hiperlinks such as:

A B C D E F G H ...

and each one goes to a smaller list with words (such as cities) beginning
with that initial letter. Just an example. Apart from programming lessons
there are user interface lessons...

--
Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com
 
Without knowing how the user interface works, I am surprised that anyone
would say this. I find it especially annoying when someone tells you
something you are doing is wrong and they do not even allow for the
possibility that you are correct. If there are any bridge players out there,
it is like telling one's partner that there is no hand they can hold that
can justify their bidding before they see partner's hand.! (6+ billion
different hands)

As an aside, I make it a practice not to answer posts with responses like
these. If someone told me that a ListBox object could not hold more than x
items and told me why, no problem. I was hoping for some suggestion as to
why the problem occurs.

I'm sure you know that the ListBox object does not spend any time drawing
items that are not in view, and TaskManager showed no excessive memory
consumption. Either the list box should work with that many items or it
shouldn't, and if it shouldn't then there should be some documentation as to
the limitations.

Once the list box is loaded, the performance is as speedy as a list box with
100 items in it, and records can be navigated to through the use of 2 text
box typing helpers and the arrow keys. Any of the 51000 items can be
selected in less than 4 seconds by someone knowing how to use the dialog. To
"narrow it down" as someone suggested takes considerably longer because of
the inherent inefficiency of having to scroll and select list box records
from several list boxes instead of one. The information is also less easily
understood when displayed as three list boxes instead of one.
 
Without knowing how the user interface works, I am surprised that anyone
would say this. I find it especially annoying when someone tells you
something you are doing is wrong and they do not even allow for the
possibility that you are correct.
Click to expand...

I'm not saying it's *WRONG*, I'm just saying making a user pick from a
listbox of 50'000 entries is generally considered very bad design.
This is not based on any particular knowledge about what you need to
do - it's just something that goes against human nature and basic
principles of UI design - no matter what it is you're trying to
achieve.

Sorry if you felt offended - I just wanted to be helpful and point out
the obvious - I'll shut up from now on

Marc


================================================================
Marc Scheuner May The Source Be With You!
Berne, Switzerland m.scheuner -at- inova.ch
 
As an aside, I make it a practice not to answer posts with responses like
these. If someone told me that a ListBox object could not hold more than x
items and told me why, no problem. I was hoping for some suggestion as to
why the problem occurs.
Click to expand...

a practical answer:

1. learn to read the documentation (but do not belive in everything you
read)
2. read the documentation on LB_INITSTORAGE message
3. think WHY and HOW it speeds things up (and why it works on NT though the
docs says it is not needed)
4. learn how to use LB_INITSTORAGE in .NET application
5. use it!

and

6. relax. no one seems offensive but apparently you think everyone is.

;)

Wiktor Zychla
 
Thank you for the reply. I try to find my answers in the documentation
before I waste other people's time, and I did examine all the
System.Windows.Form.ListBox members, but I did not see anything about a .NET
way of doing this. Is this a case where I have to use SendMessage ?
 
Thank you for the reply. I try to find my answers in the documentation
before I waste other people's time, and I did examine all the
System.Windows.Form.ListBox members, but I did not see anything about a
.NET way of doing this. Is this a case where I have to use SendMessage ?
Click to expand...

yes and there's more. you not only can preallocate list's memory to speed it
up, as I've suggested. NET does not adopt "virtual" lists, an idea used in
Win32 to display lists with huge amount of data (millions of items can be
displayed without any speed loss).

In "virtual" mode the control does not store any item data but sends to the
application messages that demand item data when it is needed to display
items. The ListBox docs says that LBS_NODATA (virtual listbox) should be
used when the amount of items "will exceed one thousand"!

my advise to use the LB_INITSTORAGE focuses then on speeding up the list in
non-virtual mode (adopted by default by .net). if you need a true speed,
read more on "virtual" lists.

quick peek at google reveals these links on virtual listboxes and listviews.

http://www.vbaccelerator.com/home/NET/Code/Controls/ListBox_and_ComboBox/VListBox/article.asp
http://addressof.com/blog/archive/2003/11/13/274.aspx

happy experimenting,
Wiktor Zychla
 
Hi Valerie,

I didn´t pretend to offend you. I was just trying to point that without a
proper design, a huge list can be a bad idea for the user, or even with a
good design if the user does not know what a textbox typing helper is
(because for novice users the first attempt will be to browse the list with
the scrollbar). Now, to the technical data: I don´t know about the listbox,
but Win32 listviews support the concept of "virtual listview", in which
items are not loaded but you are notified to supply or paint a few of them
when required. See:

http://www.google.es/search?hl=es&q=listview+virtual&meta=

The .NET Framework 1.x does not support that directly, but .NET Framework
2.0 (VS 2005) does (Listview.VirtualMode property, etc). VS 2005 is
currently in Beta 2, being the final release scheduled for 7th November.
Depending on your schedule, you may want to use it.

--
Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com
 
Back
Top