I'd like to say that this is not so outrageous as it first seems.
I did a business app (not in wx or Python) that included a
'cost center' field for some accounting information. This was
totally user-configurable. I knew from working closely with a
number of users that most useres would have 1 cost center and
few would have more than 5, so a combo box was a good choice.
However, we did get some big users and one of them called to say
that they were having trouble with the combo box, because they
had 2,000 cost centers.
I asked them how they were entering these items in their old
system, and they said that the users had a form that showed the
cost center number. I told them to set up the cost centers with
the number as the first part of the name, so that it would show
in the combo box, and everything worked fine. The widgets
that I was using it handled it fine. As long as the user typed
at least 1 key per second, it took whatever they typed as the
start of the combo box entry. They could pick a cost center by
typing in the 5-digit number, just like under the old system.
The point is that users needs vary, and it's very good if the same
widgets can handle a variety of circumstances, as this makes it
much easier for the developer to produce 1 version satisfying more
users. A virtual list box to select an item from a list of one
is not my idea of a good time.
Al
Well, it all depends on how you deploy it.
Personally I don't like Comboboxes with more than 50 entries. Simply because
only windows has the autocompletion boxes. On all other platforms you usually
have to build the autocompletion yourself.
The problem with deployment is this:
My current project is an insurance brokerage and rating system. There are for
example "Classcodes" which basically is a 5 or 6 digit number defining what
the insured is doing that might be a risk for the insurer. You can imagine
that those numbers can fill a book. Most systems have those in a Combobox.
My problem is that I only write client/server applications - meaning that you
have to fill this Combobox every time you open the dialog (or any dialog
needing classcodes). Since they don't change a lot one could download them
and cache them (which is what I'm doing). The real problem comes from the
network load. The program is designed to be used by about 500 concurrent
users. If you use a lot of those comboboxes holding 10000+ values each (maybe
not only classcodes, but zipcodes and who knows what else), you're
downloading megabytes of useless information to clients.
Therefor I avoid Comboboxes with large value lists. My approach is to usually
have a text entry field with an attached "search" button. Whenever you can't
remember the proper code to put in you can hit the searchbutton and look it
up (which will result in a request to the server to find the code).
By the end of the day most users are fine with that once they got used to it.
The dialogs respond very quickly what makes the user happy. Most of those
fields are known values anyways - at least after a while. For example most
accountants will know the costcodes they enter often, so they are much
quicker just punching them in than selecting them or looking them up in a
list.
Just go to a store - the good cashiers are those who know the codes for fuji
apples and carrots. They just look up exotic stuff like parsley roots or
sweet anise. That's the lines you want to stand in. The guys looking up
every other number not even get half the amount of customers handled in the
same time.
My 2 cents 
UC
ยทยทยท
On Thursday 19 June 2003 08:58 am, achrist@easystreet.com wrote:
I'd like to say that this is not so outrageous as it first seems.
I did a business app (not in wx or Python) that included a
'cost center' field for some accounting information. This was
totally user-configurable. I knew from working closely with a
number of users that most useres would have 1 cost center and
few would have more than 5, so a combo box was a good choice.
However, we did get some big users and one of them called to say
that they were having trouble with the combo box, because they
had 2,000 cost centers.
I asked them how they were entering these items in their old
system, and they said that the users had a form that showed the
cost center number. I told them to set up the cost centers with
the number as the first part of the name, so that it would show
in the combo box, and everything worked fine. The widgets
that I was using it handled it fine. As long as the user typed
at least 1 key per second, it took whatever they typed as the
start of the combo box entry. They could pick a cost center by
typing in the 5-digit number, just like under the old system.
The point is that users needs vary, and it's very good if the same
widgets can handle a variety of circumstances, as this makes it
much easier for the developer to produce 1 version satisfying more
users. A virtual list box to select an item from a list of one
is not my idea of a good time.
--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417