🚀 go-pugleaf

In article <1992Oct26.183209.14385@tamsun.tamu.edu> c2s4027@tamsun.tamu.edu (Cedric Sims) writes:
>In article <D88-JWA.92Oct26173144@hemul.nada.kth.se> d88-jwa@hemul.nada.kth.se (Jon Wtte) writes:
>>> c2s4027@tamsun.tamu.edu (Cedric Sims) writes:
>>
>>   I need some assistance. I need to create a list box that will hold
>>   about 4,000 items (character strings), each item occupying ~60 bytes.
>>   Of course, the standard listbox control can't handle that much data
>>   (LB_ADDSTRING begins to fail).
>>
>>
>>Warning!!! This will be the User Interface From Hell(tm)!!!
>>
>>Also, 60*4,000 is WAAAAY larger than 32k (or even 64k) meaning
>>that you will get narty and severe problems with segmentation
>>of memory.
>>
>>1) Re-think your user interface. Your users deserve something
>>better than a 4000-item list box.
>>
>     ...stuff deleted...
>
>>-- 
>> -- Jon W{tte, h+@nada.kth.se, Mac Hacker Suedoise (not french speaking) --
>>
>> "The User Interface From Hell(tm)" is a trademark of MacroSloth, Inc.
>
>This is what my users want!  A search is performed and it generates a list.
>Most of the time, only 10-20 items are found, but it is possible that a user
>can do a search that will generate >4000 items. I just can't work around that.
>In addition, the data must be ordered linearly (sound like a listbox to you?)
>
>Sorry, but re-thinking my interface is not an option. Though this listbox is
>a minor portion, it is integral to the entire system and I must have the
>ability to create a list with >4000 elements. No if's, and's, or but's.

The rest of the world uses a database and extracts a view for the display
from the database.  It costs you disk lookups, but it would allow you to
have 4000 items.  If you don't have a database, try a file.

Peter