🚀 go-pugleaf

In article <664@lax.lax.pe-nelson.com>, twbrown@PE-Nelson.COM (Tom W. Brown) 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).
|> |> 
|> |> 
|> |> 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.
|> 
|> Yes, but owner draw listboxes don't require this space.  I believe a listbox
|> reserves 4 bytes (one DWORD) for arbitrary data that may be assigned to each
|> item.  In addition, if the listbox has the LBS_HASSTRINGS style then each item
|> also has a pointer to a string (although they can all point to an empty string). 
|> So, one should be able to get about 8192 items into an owner draw listbox or 
|> 16384 if you don't use LBS_HASSTRINGS.
|> 

Oops, I just looked at the article that Kyle Marsh (kylemar@microsoft.com)
pointed out where it states that the USER code only allows up to 32 Kb for
listbox item data.  So without the LBS_HASSTRINGS style you'll only be able
to get 8160 (8192 - 32) items -- I'm not exactly sure why the missing 32.

With the LBS_HASSTRINGS style, the string pointers are only 16 bit offsets,
so one can get 5440 items in the list.

In any case, apologies for the misstatement!


----------------------------------------------------------------------------
Tom Brown               |      "I stand by all my misstatements"
PE Nelson Systems       |  
twbrown@pe-nelson.com   |                                 Dan Quayle
----------------------------------------------------------------------------