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?
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.
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?
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.
Quote from: Gunner on November 28, 2009, 05:23:17 AM
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:
QuoteMyProc 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...
Hi Gunner,
You can use the file data assembler tool to embed the text as binary data in your executable :
\masm32\fda.exe
Quote from: hutch-- on November 28, 2009, 06:42:47 AM
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:
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.
In my crude test, with the timings done entirely in the WM_INITDIALOG handler, preceding the LB_ADDSTRING loop with an appropriate LB_INITSTORAGE (http://msdn.microsoft.com/en-us/library/bb761319(VS.85).aspx) message reduced the time by a few percent.
Quote from: MichaelW on November 28, 2009, 06:06:53 PM
In my crude test, with the timings done entirely in the WM_INITDIALOG handler, preceding the LB_ADDSTRING loop with an appropriate LB_INITSTORAGE (http://msdn.microsoft.com/en-us/library/bb761319(VS.85).aspx) 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.
Quote1 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
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
LockWindowUpdate isn't what to use, WM_SETREDRAW is.
QuoteThis message can be useful if an application must add several items to a list box.
Quote from: hutch-- on November 28, 2009, 11:53:56 PM
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.
Quote1 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
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.
Quote from: hutch-- on November 29, 2009, 06:04:02 AM
20k to 30k of strings, not byte size
Sorry, I overlooked "of strings"
:bg