1. RE: Listviews and time....
Euman wrote:
> global function addLVItem(integer id,atom iIcon,sequence text)
>
> Bahh, RECURSIVE AS HELL
>
> What's wrong with it? Everything if you have alot of info to
> feed your LV!
>
> I was hopeing someone might have an idea how to load in a
> couple thousand
> items to a Listview in a timely manner....
Done.
This has been coded for the new version.
result = Dispatch( integer id, "addItems", sequence items)
where 'id' is the ID for a Listview, Treeview, List, Combo, or imagelist
'items' is a list of items.
For text only items, each element is a text sequence,
image only items, each element is either a hWnd to a bitmap, or a
filename.
text + image items (like listviews) , each element is a 2-element
sequence
of atom(Icon) and sequence(Text)
eg.
sequence result
result = Dispatch(myListView, "addItems",
{ {wipIcon, {"lib101","Bug","setTextColor() for edit
controls."}},
{doneIcon, {"lv027","Enhanc", "New addItems()"}},
{doneIcon, {"tv012","Enhanc", "New addItems()"}},
})
if result[1] = -1 then
-- Function not supported
... do it the long way ...
end if
This also demonstrates the new Dispatch() function, which allows for
optional functionality to be implemented. This means that a mild form of OO
polymorphism is available. It also enables "light" versions of win32lib to
be created.
This is all optional as all the current functions still exist and no-one has
to go a rewrite their win32lib code 
Oh, except if your are creating your own imagelists. The current
implementation only allowed for 32x32 or 16x16 pixel images. To cater for
more general imagelist usage I've changed the way the create() parameters
are interpreted. So let me know if this is going to hurt your code, anyone.
-----------
cheers,
Derek Parnell
2. RE: Listviews and time....
Euman wrote:
> OfCourse those of us who insist on fast will re-write code/
> I haven't had a win32lib that I didnt have to re-code for...
Please feel free to send in your improvements. I don't want win32lib to be
slow either!
Other changes in the new version include
a) the "_full" code has extra error and parameter checking embedded but
the stripped down editions don't. I achieved this by adding ...
--ASSERT
. . .
--END ASSERT
segments in the code and the EuCompress program strips these segments out.
b) I tried to use faster datatypes were possible, eg integer rather than
atom or object.
c) The inner stack operations used by event handlers are now much faster
due to a pre-allocated stack size rather than use growing and shrinking
sequences.
-----------
cheers,
Derek Parnell
3. RE: Listviews and time....
Euman wrote:
> I was hopeing someone might have an idea how to load in a couple
> thousand
> items to a Listview in a timely manner....
Euman,
I submitted to Matt Lewis a change I suggested to Win32Lib to address
this problem. The issue is the sendMessage function for adding items
into a list view uses LPSTR_TEXTCALLBACK (or something like that). This
tells the list view to issue a callback to get the text of the item.
Unfortunately it must call back for EVERY item/column in your list view.
And you're right, it's VERY slow.
I overcame this in the ODBC SQL utility I submitted to the user
contributions page. I coded my own sendMessage functions supplying the
text to put into the list view. No callback. Runs much faster.
Although with this fix you can't allow the column headers to be sorted
since this would require going through Win32Lib's functions to add list
view items.
I don't know if this is something that will be addressed in the next
version or not...Derek?
Hope this helps,
Jonas
