easiest way to include a lot of text

[Gunner]

What would be the easiest and most efficient way of including a lot of text with my prog?  I have a list of MIME content types I want to fill a listbox (or something) with, should I add em all to a resource dll (like I did with the error codes for MELT) or is there a better way?

[hutch--]

Rob,

Are you talking of large quantities of text ?

If its a fixed list and it needs to be both large and fast I would be inclined to do a dedicate binary block with a specified format.

count,os1,os2,os3 etc ....

os1 text zero
os2 text zero
os3 text zero

You would need to write a tool to do this but its just a sequence of DWORDS, the first being the item count, the rest being offsets from the start and the rest are data at those offsets zero terminated.

Once you have it in binary form, plonk it into a data module.

[Gunner]

Large quantities? yes kinda of, I want to populate a listbox or treeview with text like the following

• application/x-dvi
• audio/x-jam
• model/iges
• multipart/x-zip

etc...

there are over 100 descriptions.  Could you explain more on the binary block?

[hutch--]

Rob,

It would not be worth the effort for a small number like that. When you fill the list box, just turn off the display update, feed them in one at a time then turn the display update back on again. This is plenty fast enough into the thousands of entries.

If you want them displayed in the order you write them, don't set the list box as sorted.

[jj2007]

Large quantities? yes kinda of, I want to populate a listbox or treeview with text like the following

• application/x-dvi
• audio/x-jam
• model/iges
• multipart/x-zip

etc...

there are over 100 descriptions.

100 is a lot, and they will keep changing. Sure you want to include them in the executable? It's a lot more flexible to keep them in a text file:

MyProc proc
   Recall "\Masm32\include\Windows.inc", L$()
   For_ n=0 To 50      ; replace 50 with eax-1 to get the full file (it will take 0.5 seconds then)
      .if Len(L$(n))
         sm hListbox, LB_ADDSTRING, 0, L$(n)
      .endif
   Next
   ret
MyProc endp

Sample attached. Just replace windows.inc with your file...

[Vortex]

Hi Gunner,

You can use the file data assembler tool to embed the text as binary data in your executable :

Code Select Expand

\masm32\fda.exe

[jj2007]

When you fill the list box, just turn off the display update, feed them in one at a time then turn the display update back on again. This is plenty fast enough into the thousands of entries.

Hutch,
I've played around a bit. With windows.inc, 22276 entries, filling the listbox takes half a second. LockWindowUpdate has no effect, hiding the box neither. If I add the LBS_SORT style, it takes almost a second.

Filling listboxes was definitely slow in Win 3.1, if the box was visible, but it seems this problem has disappeared.

EDIT: I keep playing but must admit the behaviour is inconsistent.
Edit(2):
Hiding the listbox is more efficient than LockWindowUpdate:

Code Select Expand

546 ms for 22276 entries with ShowWindow SW_HIDE ON
1329 ms for 22276 entries with ShowWindow SW_HIDE OFF
937 ms for 22276 entries with LockWindowUpdate ON
1297 ms for 22276 entries with LockWindowUpdate OFF

Timings for style WS_VSCROLL. If you take the scroll off, all 4 versions run at 500 ms.
LBS_SORT instead makes the code only roughly 50% slower.

[MichaelW]

In my crude test, with the timings done entirely in the WM_INITDIALOG handler, preceding the LB_ADDSTRING loop with an appropriate LB_INITSTORAGE message reduced the time by a few percent.

[jj2007]

In my crude test, with the timings done entirely in the WM_INITDIALOG handler, preceding the LB_ADDSTRING loop with an appropriate LB_INITSTORAGE message reduced the time by a few percent.

Thanks, Michael. In combination with SW_HIDE, it is much more than a few percent. Very interesting.

1   Listbox   My$   594    ms for 22276 entries with ShowWindow SW_HIDE ON
2   Listbox   My$   1312    ms for 22276 entries with ShowWindow SW_HIDE OFF
3   Listbox   My$   938    ms for 22276 entries with LockWindowUpdate ON
4   Listbox   My$   1296    ms for 22276 entries with LockWindowUpdate OFF
1   Listbox+INITSTORAGE   My$   47    ms for 22276 entries with ShowWindow SW_HIDE ON
2   Listbox+INITSTORAGE   My$   703    ms for 22276 entries with ShowWindow SW_HIDE OFF
3   Listbox+INITSTORAGE   My$   329    ms for 22276 entries with LockWindowUpdate ON
4   Listbox+INITSTORAGE   My$   703    ms for 22276 entries with LockWindowUpdate OFF

[hutch--]

The issue of loading 20 or 30 k of strings into a list box is not a speed issue, its a display issue and it can look very messy with that many additions. You turn the display off so it does not repeatedly flash while loading the strings.

There is great virtue in using documented techniques for interface junk, it may even work the same way on a later OS version if you are plug lucky and the next revisionist does not PHUK it up any further.  :P

[sinsi]

LockWindowUpdate isn't what to use, WM_SETREDRAW is.

This message can be useful if an application must add several items to a list box.

[jj2007]

There is great virtue in using documented techniques for interface junk

You are so right, Hutch! So now I am using the documented technique suggested by Sinsi. Not for 20 or 30k, but for the 840k of Windows.inc, on a slow Celeron M.

1   Listbox+INITSTORAGE   My$   31    ms for 22276 entries with   WM_SETREDRAW on
2   Listbox+INITSTORAGE   My$   703    ms for 22276 entries without WM_SETREDRAW off
3   Listbox+INITSTORAGE   My$   328    ms for 22276 entries with LockWindowUpdate ON
4   Listbox+INITSTORAGE   My$   703    ms for 22276 entries with LockWindowUpdate OFF

[hutch--]

JJ,

20k to 30k of strings, not byte size. It is a good technique you are using, I have only ever bothered to use WM_SETREDRAW to turn off the display while updating a list box but the memory option after clearing the list box is a good idea and documented by Microsoft.

None the less, I doubt that Rob will see the difference with his hundred or so items.

[jj2007]

20k to 30k of strings, not byte size

Sorry, I overlooked "of strings"
:bg