Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Problem on loading a dialog box.
7 views
Skip to first unread message
Dom
May 14, 2012, 1:51:28 PM5/14/12
to
In my application, the user can bring up a dialog box that contains a
listbox. The listbox has about 6000 items, obtained by reading a
table in a Database. The dialog box is brought up every minute or so,
and I do not want the user to wait for that dialog box to rebuild the
listbox each time.
I see this done often enough. For example, in the CSharp studio
itself, the intellisense window pops up regularly, without a moment's
pause, and it contains much more than 6000 items. I assume the box is
being built just once, and then the popping on and off is just a
matter of making it visible and invisible.
How do I do this? Right now, the dialog box is never disposed in the
calling procedure. I just have a static variable that holds it, and
then I call frmWindow.ShowDialog (this), when I need it. And when the
user gives an answer, I call this.Close() to end it.
But still there is a pause, and using the debugger, I can see that the
dialog box is calling each items ToString() method, so I assume this
is being done just to repaint the listbox. Is there a better way?
listbox. The listbox has about 6000 items, obtained by reading a
table in a Database. The dialog box is brought up every minute or so,
and I do not want the user to wait for that dialog box to rebuild the
listbox each time.
I see this done often enough. For example, in the CSharp studio
itself, the intellisense window pops up regularly, without a moment's
pause, and it contains much more than 6000 items. I assume the box is
being built just once, and then the popping on and off is just a
matter of making it visible and invisible.
How do I do this? Right now, the dialog box is never disposed in the
calling procedure. I just have a static variable that holds it, and
then I call frmWindow.ShowDialog (this), when I need it. And when the
user gives an answer, I call this.Close() to end it.
But still there is a pause, and using the debugger, I can see that the
dialog box is calling each items ToString() method, so I assume this
is being done just to repaint the listbox. Is there a better way?
mick
May 15, 2012, 5:13:21 AM5/15/12
to
"Dom" <doliv...@gmail.com> wrote in message
news:e0500e57-415d-43d8...@n42g2000yqm.googlegroups.com...
mick
Dom
May 15, 2012, 8:17:18 AM5/15/12
to
On May 15, 5:13 am, "mick" <coughco...@privacy.com> wrote:
> "Dom" <dolivas...@gmail.com> wrote in message
> mick- Hide quoted text -
>
> - Show quoted text -
Yes, I have. The same thing happens, plus, after the Hide(), the
focus does not always go back to the parent window. Sometimes it goes
to a different application running at the same time, and the user
needs to go to the task bar.
Dom
> "Dom" <dolivas...@gmail.com> wrote in message
>
> - Show quoted text -
Yes, I have. The same thing happens, plus, after the Hide(), the
focus does not always go back to the parent window. Sometimes it goes
to a different application running at the same time, and the user
needs to go to the task bar.
Dom
Peter Duniho
May 15, 2012, 10:32:34 AM5/15/12
to
On Tue, 15 May 2012 10:13:21 +0100, mick wrote:
> [...]
is called anyway.
As far as the original question goes: the bottom line is that 6000 items is
a HUGE number of items for any ListBox to contain, and for any user to have
to navigate.
I don't recall seeing any Intellisense window that contained even that
many, never mind "much more than" that many. However, for situations where
this amount of data is going to be displayed (whether it's a good idea or
not...sometimes it is, but more often it's not), the usual approach for
performance is to "virtualize" the display of the items.
That is, rather than having a control that is fully populated with a large
number of items all at once, have a program-maintained data structure
containing just the minimal amount of data necessary (e.g. an array of
strings themselves), and then reference that data structure as needed to
draw the individual items in the control (i.e. rather than expecting the
control to not only maintain the whole list of data items and also to
convert from a non-string object to a string in real-time as the control is
drawn).
At the very least, the OP should populate the ListBox with actual string
objects, not some other object that needs its ToString() method called for
display. And to really handle that number of list items efficiently, they
should look into "owner-draw" items, or even a fully custom implementation
of a list box where they have full control over the entire rendering code
path.
Pete
> [...]
>> How do I do this? Right now, the dialog box is never disposed in the
>> calling procedure. I just have a static variable that holds it, and
>> then I call frmWindow.ShowDialog (this), when I need it. And when the
>> user gives an answer, I call this.Close() to end it.
>>
>> But still there is a pause, and using the debugger, I can see that the
>> dialog box is calling each items ToString() method, so I assume this
>> is being done just to repaint the listbox. Is there a better way?
>
> Have you tried using Hide() instead of Close()?
A modal Form (as here) is only ever actually hidden when the Close() method
>> calling procedure. I just have a static variable that holds it, and
>> then I call frmWindow.ShowDialog (this), when I need it. And when the
>> user gives an answer, I call this.Close() to end it.
>>
>> But still there is a pause, and using the debugger, I can see that the
>> dialog box is calling each items ToString() method, so I assume this
>> is being done just to repaint the listbox. Is there a better way?
>
> Have you tried using Hide() instead of Close()?
is called anyway.
As far as the original question goes: the bottom line is that 6000 items is
a HUGE number of items for any ListBox to contain, and for any user to have
to navigate.
I don't recall seeing any Intellisense window that contained even that
many, never mind "much more than" that many. However, for situations where
this amount of data is going to be displayed (whether it's a good idea or
not...sometimes it is, but more often it's not), the usual approach for
performance is to "virtualize" the display of the items.
That is, rather than having a control that is fully populated with a large
number of items all at once, have a program-maintained data structure
containing just the minimal amount of data necessary (e.g. an array of
strings themselves), and then reference that data structure as needed to
draw the individual items in the control (i.e. rather than expecting the
control to not only maintain the whole list of data items and also to
convert from a non-string object to a string in real-time as the control is
drawn).
At the very least, the OP should populate the ListBox with actual string
objects, not some other object that needs its ToString() method called for
display. And to really handle that number of list items efficiently, they
should look into "owner-draw" items, or even a fully custom implementation
of a list box where they have full control over the entire rendering code
path.
Pete
Dom
May 15, 2012, 10:47:00 AM5/15/12
to
On May 15, 10:32 am, Peter Duniho <NpOeStPe...@NnOwSlPiAnMk.com>
wrote:
Some good ideas, here. I'll think about virtualizing the listbox, and
using strings instead of Class.ToString(). For the sake of my
reputation, let me add a few points:
1. The user types into a text box. The list box scrolls around to
keep track of the typing, as is done in Intellisense. The user does
not acutally use the scroll bar to find an item.
2. Intellisense seems to have several thousand items. First there is
the top level item list, then when the "dot" is typed, you have the
second level items, and so on. At some point, all those items are
stored, although maybe several different boxes are used.
wrote:
using strings instead of Class.ToString(). For the sake of my
reputation, let me add a few points:
1. The user types into a text box. The list box scrolls around to
keep track of the typing, as is done in Intellisense. The user does
not acutally use the scroll bar to find an item.
2. Intellisense seems to have several thousand items. First there is
the top level item list, then when the "dot" is typed, you have the
second level items, and so on. At some point, all those items are
stored, although maybe several different boxes are used.
Dom
May 15, 2012, 10:49:35 AM5/15/12
to
>
> - Show quoted text -
Sorry, I can't use strings. I need the class itself. When a user
> - Show quoted text -
selects an item from the box, I need other information on that item.
Would using a data structure of some sort be much faster?
Dom
May 15, 2012, 2:34:58 PM5/15/12
to
>
> - Show quoted text -
I did the virtualize bit. Works like a charm. Thanks, Peter, for the
> - Show quoted text -
advice.
Dom
Peter Duniho
May 16, 2012, 12:27:11 AM5/16/12
to
On Tue, 15 May 2012 11:34:58 -0700 (PDT), Dom wrote:
> I did the virtualize bit. Works like a charm. Thanks, Peter, for the
> advice.
Happy to help. For future reference:
> I did the virtualize bit. Works like a charm. Thanks, Peter, for the
> advice.
-- You can still populate a ListBox with string instances, and then map
back to the correct object with a Dictionary or similar. Alternatively,
you could populate with a wrapper object that contains the pre-computed
string, as well as a reference to the original object. Of course, this all
assumes that the overhead of computing the string instances (either the
computation itself or the garbage collection overhead that results) is
what's slowing things down. That may or may not be the case.
-- As far as Intellisense goes, I'm sure that at the very least, they
populate only what they need at the time. If you type the period between
members, you get a whole new context-sensitive list. At any given time,
the list is likely to number in the hundreds at the most, and usually only
dozens or less. And of course, Intellisense display is likely a completely
custom control, so it's essentially going to be inherently "virtualized" as
well.
Anyway, glad to hear you got your performance issue straightened out.
Pete
0 new messages