Listview performance question

  • Thread starter Thread starter whistler
  • Start date Start date
W

whistler

I use a listview in one of my forms to load approx. 800 records.
Each row has 5 subitems, so six columns in all.

I load the records by walking through a dao recordset rst something like this

set lv = me.listview1.object
set qd = currentdb.querydefs ("SomeQuery")
set rst = qd.openrecordset
rst.movefirst
while not rst.eof
set li = lv.listitems.add (,,rst!field1)
li.subitems(1) = rst!field2
.....
rst.movenext
wend

Works fine, only performance is quite bad....

I already turn off application.echo before this code (and on again afterwards), which helps a bit, but not really.

Any suggestions ? (Adding indexes to fields in the table underlying qd, using other strategy of populating records, or.....)

Any hint is greatly appreciated....

Jos



--------------= Posted using GrabIt =----------------
------= Binary Usenet downloading made easy =---------
-= Get GrabIt for free from http://www.shemes.com/ =-
 
Hi,
first of all - I don't think that loading 800 items in listview is a good
idea, there is no sense, so suggest to redesign this, for example you can
add some filter.

Anyway - you can use sendmessage API to switch on/off LV redraw during load:

Public Declare Function SendMessage Lib "user32" Alias "SendMessageA" _
(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As _
Any) As Long

Public Const WM_SETREDRAW = &HB

SendMessage oLV.hWnd, WM_SETREDRAW, 0, ByVal 0&
'load here
SendMessage oLV.hWnd, WM_SETREDRAW, 1, ByVal 0&

you can check my treeveiw sample to this method usage:
http://www.pointltd.com/Downloads/Details.asp?dlID=36

--
Best regards,
___________
Alex Dybenko (MVP)
http://accessblog.net
http://www.PointLtd.com
 
whistler said:
I use a listview in one of my forms to load approx. 800 records.
Each row has 5 subitems, so six columns in all.

I load the records by walking through a dao recordset rst something like this

set lv = me.listview1.object
set qd = currentdb.querydefs ("SomeQuery")
set rst = qd.openrecordset
rst.movefirst
while not rst.eof
set li = lv.listitems.add (,,rst!field1)
li.subitems(1) = rst!field2
....
rst.movenext
wend

Works fine, only performance is quite bad....

Why not just base the listview control directly against that query
using the listview controls row source instead of loading it via code?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Alex Dybenko said:
What do you mean with "listview controls row source"? not sure I see such
property

I was thinking of a listbox not a listview control.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
David W. Fenton said:
What's a "listview" control? Is that some new native control in
A2K7? Or is it an add-in control?

It's a companion control to treeview. In Windows Explorer treeview is
the left hand side and listview is the right hand side. Or something
like that. Old stuff really.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
It's a companion control to treeview. In Windows Explorer
treeview is the left hand side and listview is the right hand
side. Or something like that. Old stuff really.

Tried it back in 1998 or so, couldn't get it to be portable from one
PC to another, so abandoned it.

Can't imagine why anyone would muck around with such a mess, unless
it's been vastly changed so that:

1. it is portable

2. it's not so damned slow as to be useless.
 
Control resides in comctl32.ocx or mscomctl.ocx, was widely used
in vb5/6, and not so much used in access.

I wonder why MS never chose to provide Access with a native treeview
control, given how ubiquitous it has become in MS apps.
 
Hi,
I think they tried in Access 2 time, it was a treeview, which you could bind
to recordsources, like listbox, but comctl treeview functionality is much
richer, that is why this treeview left only, and was included in developer
edition (I think)

--
Best regards,
___________
Alex Dybenko (MVP)
http://accessblog.net
http://www.PointLtd.com
 
I think they tried in Access 2 time, it was a treeview, which you
could bind to recordsources, like listbox, but comctl treeview
functionality is much richer, that is why this treeview left only,
and was included in developer edition (I think)

I never saw a treeview in Access 2, since that predated the
introduction of ubiquitous treeview controls with Win95.

This still doesn't answer the question why they never made a control
that integrated seamlessly into Access. If they had fixed the speed
problems, I'd have used it, but given the incompatibilities *and*
the slowness, I never considered it for production use.
 
David W. Fenton said:
I wonder why MS never chose to provide Access with a native treeview
control, given how ubiquitous it has become in MS apps.

Totally agree with you.

I'm told you can purchase German commented API source code. I have
not done so. <smile>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
David W. Fenton said:
Tried it back in 1998 or so, couldn't get it to be portable from one
PC to another, so abandoned it.

Similar experience with Treeview.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Back
Top