PC Review


Reply
Thread Tools Rate Thread

Re: ListBox Row Source Calling function and seems recursive

 
 
Albert D. Kallal
Guest
Posts: n/a
 
      8th Sep 2004
"nach" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In ListBox Row Source Type We call FillList
>
> Public Function FillList(fld As Control, ID, Row, col, Code)
> Select Case Code
>
> What does the code represent ?
> The Code keeps on changing which as a result calls itself again
>
> Can someone explain ???


The above uses the call back feature of a listbox, or a combo box.

It is a great approach to filling a listbox, or comb box. In fact, often it
is MUCH better then using string and a "value list"

The reasons are as follows:

Building a long string and having to concat values is slow. (especially when
the length of strings gets over 200 characters).

For the combo box to display a value from the long string, the string must
be parsed, and string parsing is costly in terms of processing.

To update, or show any changed values, a string must be re-generated each
time. So, if your combo or list box values need to change, then again, using
one big long unwieldy string is slow, and hard to deal with...and as
mentioned, you can't effect change values in that string, so, you have
re-generate the string each time.

The max length of a "value list" string is 4000 characters. Thus, with a
listbox of 5 or 6 rows, and each row being 50 characters...you can't even
display 100 rows....as you already passed the max limit.

Worse, using a delimiter string means the data in the string cannot have any
delimiters..as this will mess up the combo box display.

Also, using the call back function is much less code then building up a long
string with delimiters. Also, making sure each row/column matches up in a
value list is harder (then used an array that is dimensioned to the same
number of rows and columns that the combo will display).

Processing is not a here. Computers are crazy fast. The fact that for each
cell, the call back gets called is not a problem, and, in fact for a value
list, each cell has to PARSE OUT the value out of a long string..(this is
actually MORE processing!). So, the fact of executing 6 columns x 100 rows
only equals 600 calls...and that is virtually nil in terms of processing.
For a string, you get 600 parses out of a delimited string. So, when
comparing the two approaches, there is little if any noticeable difference.

Best of all, you can map a combo box, or list box to values in an array.
And, that array can be filled from data via GETROWS. To build up a muilti
column string with data from a reocrdset requites looping code. (GETROWS can
send the data right to an array for you. I should note that you would only
send the data to an array if special processing needs to be done on the
data, else it best to simply make the combo box source the sql you used to
make the reocrdset..and *then* use GETROWS to fill the array for the combo
box.

There is an example here of how the call back works:
http://www.mvps.org/access/forms/frm0049.htm

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
http://www.pcreview.co.uk/forums/(E-Mail Removed)
http://www.attcanada.net/~kallal.msn


 
Reply With Quote
 
 
 
 
david epsom dot com dot au
Guest
Posts: n/a
 
      8th Sep 2004
An alternative opinion:

We use a string list to cache the values, so that we don't need to do as
many database lookups.
We have generic code to create string lists from queries.
We thought the string list (with generic code) was simpler and faster than
the callback function.
But we had already started using code to cache database lookups.
And it does limit the number of items.

(david)



 
Reply With Quote
 
 
 
 
Albert D. Kallal
Guest
Posts: n/a
 
      8th Sep 2004
"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:(E-Mail Removed)...
> An alternative opinion:
>
> We use a string list to cache the values, so that we don't need to do as
> many database lookups.


Actually, in am in full agreement that strings are fine, and in I would even
agree that in MOST CASES, strings are a fine choice..and if you bought me
small coffee...I could even agree with you that strings are BETTER then call
back.

And, for most cases, strings are somewhat easier to use then the call back.
However, when you start having to deal with multi-columns etc, then GETROWS
to an array is not such a bad choice. (and, no loop code needs be written).

So, I think there are some advantages to call back...it really going to
depend on the particulars situation.

But...sure...most of the time a delimited string is fine...and *most* of the
time that delimited string is less work then call back!


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)
http://www.attcanada.net/~kallal.msn


 
Reply With Quote
 
 
 
Reply

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Get full path directory list on both recursive and non-recursive dircommand Scott Bass Windows XP General 5 14th May 2010 01:50 PM
What are: "Control Source" , "Row Source" and "Row Source Type" ? ali Microsoft Access Forms 1 14th Jan 2008 03:12 AM
ListBox with header row, delete row, protect header row =?Utf-8?B?bWlrZW9sc29u?= Microsoft Excel Programming 2 12th Mar 2007 03:59 AM
Re: ListBox Row Source Calling function and seems recursive Brendan Reynolds Microsoft Access VBA Modules 0 7th Sep 2004 03:53 PM
Re: ListBox Row Source Calling function and seems recursive '69 Camaro Microsoft Access VBA Modules 0 7th Sep 2004 03:52 PM


Features
 

Advertising
 

Newsgroups
 


All times are GMT +1. The time now is 11:04 AM.