[AccessD] cbo Callback - method

jwcolby jwcolby at colbyconsulting.com
Fri May 16 12:09:04 CDT 2008


The first email contained a complete module.  The second email contained 
a complete class module.

The function cboCallback contained in the module is called from the 
combo.  In order to make it automagic, you need to use a naming 
convention, qCboName for the query name.  As long as the query exists 
and contains the correct data for the combo of that name, the data will 
load into an array the first time that any combo calls cboCallBack, and 
the array will be stored into the collection.  The second and subsequent 
times the data will be in the collection and will just be pulled out and 
used without hitting the table again.

As an example a combo named cboState will cause qcboState to load the 
very first callback, but from then on any cbo state anywhere in the 
system will use the data in the array, stored in the collection in the 
class.

This means that only queries that do not change the data contents 
(static data) can use this function.

In order to discover WHICH combo is currently calling the callback, and 
more importantly that a DIFFERENT combo is now calling the callback, I 
store the CURRENT control name in the class.  When the control name 
changes, the code goes to mInit() and tries to load the data for the 
current combo from the collection.  If that fails, then a recordset is 
opened, data is loaded into the array, and the array is stored in the 
collection and used in the callback method of the class until the next 
combo control name change.

John W. Colby
www.ColbyConsulting.com


Drew Wutka wrote:
> What's holding it?  Is this a bas module, or a class module,that
> contains the callback function?
> 
> Drew
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Friday, May 16, 2008 11:42 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] cbo Callback - method
> 
> Drew,
> 
> That is not happening here.  I place a debug.Print in the init event of 
> the class and it fires exactly once.  In fact I can close and reopen the
> 
> test form and it does not fire again (as it should not).
> 
> This code in the main function:
> 
>       '
>       'checks if the class is initialized
>       If mclsCallback Is Nothing Then
>           Set mclsCallback = New clsCallBack
>           If mdb Is Nothing Then
>               Set mdb = CurrentDb
>           End If
>       End If
> 
> checks if the mclsCallback is initialized and does not initialize it
> again.
> 
> 
> John W. Colby
> www.ColbyConsulting.com
> 
> 
> Drew Wutka wrote:
>> Do you realize that you are creating an instance of this class for
> each
>> callback?
>>
>> No wonder it's sluggish! (To check, but a debug statement into your
>> initialize event).
>>
>> Drew
> 



More information about the AccessD mailing list