>>>Some people are learning while others are stubborn. There are people who build a system with a combobox for picking a customer in an invoice. It works for years - like that means it's a good design - and suddenly it breaks. So they come here and say I've got a combobox with 100,000 customers in it. It's working for years. Why suddenly is it a problem?
>>>
>>>The common response now is: why are you putting 100,000 customers in a combobox? Don't you know any better? Some people have tried to fix the combobox so you get that thread started.
>>>
>>>Others with such systems come to his support and say, I've got a system with comboboxes with 1000 items and it's fine! Another thread.
>>>
>>>There is no engineering body that tells us:
>>>
>>>1 - It's almost always a problem to fetch too much data.
>>>
>>>2 - A design should work for large data sets and small data sets. What is needed is an alternative combobox which grabs small amounts of data from a table as the user types, or pages through the whole set of data as the user scrolls through the list, WITHOUT prepopulating with ALL the data, EVER. That design would work for large sets and tiny sets. But oh no, we'll never agree on a single design, so we have 15 ways to do everything and you'll get 15 different answers to dealing with this problem.
>>>
>>>Having made that suggestion, some will then say: That's absurd. Comboboxes are necessary. I use them all the time. They're fine. Sure, from a limited perspective, anything may be "fine".
>>>
>>>We're not all looking towards a solution that works for us all. I think people are mostly looking for solutions that work for each of them RIGHT NOW.
>>>
>>>Just my 2 cents.
>>
>>That's about a dollar - 80! :-)
>>
>>Why are you talking about comboboxes when he's talking about Kias?
>
>I also don't see a connection between Kia and a combobox. But that's why we're here for - to degenerate every thread... <g>

It a dirty job, but somebody has to do it.