[AccessD] Strategies for populating combo boxes

Gustav Brock Gustav at cactus.dk
Tue Nov 7 08:31:53 CST 2006


Hi Don and Shamil

One method to speed up a callback function is to use a static array as the source. When initializing, check if the array is empty - if not, fill it. Now, whenever the combo or listbox is requeried and that happens very often, the callback function reads from the static array which is very fast.

Here's an example:

Public Function OrderListPrint( _
  ctl As Control, _
  ID As Long, _
  row As Long, _
  col As Long, _
  Code As Integer)
  
  Static astrPrint(1 To 7) As String
  
  Dim varValue            As Variant
  Dim lngCount            As Long
  
  Select Case Code
    Case acLBInitialize
      If Len(astrPrint(1)) = 0 Then
        ' Fill array.
        For lngCount = 1 To 7
          astrPrint(lngCount) = GetMsg("SaleId90" & lngCount)
        Next
      End If
      varValue = True
    Case acLBOpen
      varValue = Timer
    Case acLBGetRowCount
      varValue = 7    ' Rows.
    Case acLBGetColumnCount
      varValue = 2    ' Columns.
    Case acLBGetColumnWidth
      varValue = -1   ' Column width.
    Case acLBGetValue
      If col = 0 Then
        varValue = row + 1
      ElseIf col = 1 Then
        varValue = astrPrint(row + 1)
      End If
    Case acLBGetFormat     ' Format the data.
      ' varValue = strFormat      
    Case acLBEnd
      ' Do something when form with listbox closes or
      ' listbox is requeried.
  End Select
  
  OrderListPrint = varValue
    
End Function

/gustav

>>> shamil at users.mns.ru 07-11-2006 13:19:36 >>>
<<<
It seems like an interesting option.
>>>
Don,

Yes, that is an interesting and useful option but be careful with combos
having many entries filled by callback functions while using them in
datasheet/continuous view forms - AFAIKR such combos are refilled every time
they get shown while you're scrolling rows - as a result you get "brain
damaged" datasheet forms reacting very slowly while scrolling them: if you,
e.g. have a combo, which is filled by callback function in half a second
them for a datasheet form with 10 visible rows this combo's filling will
take ~5 seconds when you push [PgDn]/[PgUp]...

Talking about that from memory - last time I used combos with callback
functions in MS Access 97 and I had met this nasty side-effect effect
mentioned above. Did they (MS) fix the issue in MS Access 2000/XP/2003/2007?
- I doubt they did but I can be wrong and therefore my above remark has to
be retested...

Temporary tables refilled on demand are usually satisfactory when used as a
base of dynamic combos. Of course these temp tables should be kept in
dedicated temp databases, which should be automatically compacted once in a
while...

Temp tables or dynamic on demand SQL used for combos' rowsource when combos
get focus of user typed a few chars are not the source of the "brain damaged
datasheet" side effect - the easy guess here is that MS Access "knows" (/get
cached) all the entries of such combos and therefore it (MS Access) is able
to go through all the visible rows and to keep shown/clear combos' values -
in the case of callback functions it (MS Access) have to get combos' entries
for every combo of every (newly) displayed row....

--
Shamil
 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com 
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of McGillivray, Don
[IT]
Sent: Tuesday, November 07, 2006 7:36 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Strategies for populating combo boxes

Wow.  I stepped away for a couple of days and find a full blown discussion
in my wake.  

There's only one table and it has about 1.1 million records and 35 columns,
only about 10 of which contain data that they want to be able to select from
the combos.  I settled on a temp table to hold the desired lists.  Col 1 has
the control's name, col 2 the value.  The report selection form sets the
rowsource for each combo on open.  Takes only a few seconds.  I added a
routine to populate the temp table upon demand whenever the main table has
been refreshed (about once per quarter, I'm told.)  So far, there are no
more than about 27K rows in the largest combo list.  The others are in the
tens or hundreds.  I'm glad to know of the limit, though.  I'll be able to
warn of a potential for difficulty there.  

Drew, thanks for the idea about callback functions.  And, JC, thanks for the
warnings about comprehending them.  I've looked at them before and didn't
quite get it.  I feel better knowing that even you found them head-twisting.
I'll have another go.  It seems like an interesting option.

Thanks to all for the suggestions!

Don

-----Original Message-----
From: accessd-bounces at databaseadvisors.com 
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com 
Sent: Friday, November 03, 2006 3:11 PM
To: accessd at databaseadvisors.com 
Subject: Re: [AccessD] Strategies for populating combo boxes

Oh, well I only use a callback when it's called for. (pun intended).  Most
common functions of a callback are just fine for 99% of what you need a
combo for.  The callback functionality is best for that other 1%.  For
instance, I wrote a utility that let you print or preview reports in a
database.  Using a value list runs into trouble if you have too many
reports, because it can only be ~2048 characters in length.  A callback did
the trick.

Also in tricky situations, like the one described in this thread, callbacks
provide better control of a combo/listbox.

Drew



More information about the AccessD mailing list