[AccessD] ParamArray problem

John W. Colby jwcolby at colbyconsulting.com
Sat Mar 13 12:31:18 CST 2004


Arthur,

In the end you never pass objects, only pointers to objects.  Only the
smaller data types such as integers, floats etc can actually be "passed by
value", everything else is passed by reference, i.e. a pointer to the
object.

Let's back up a moment.  Did you read the last issue of my framework
discussion (which in itself is a misnomer since no one is really responding
in a technical manner).  The form class - dclsFrm runs a control scanner
where it iterates the controls collection of the form, instantiating class
for each control found.  A POINTER to each class instance is saved in the
form's collection.

So... in the case we are discussing, the form now "knows about" (for the
sake of argument) 30 controls of which 3 are combos.  Every one of these
controls has an associated class loaded and (pointers) stored in the
collection in the form class.  Now, after running that scanner the developer
needs to "inform" one combo that 3 other objects (combos, lists, subforms
etc) are dependent on it.  Thus a ParamArray.  With one call I can pass in a
pointer to all three dependent objects.  The dependent class takes the
array, pulls the pointer to the classes that I passed in, and loads them
into its own collection.  Not that class' Requery method is called, the
class can call the requery method of each item in that collection.

BTW, I am actually doing this in the example code I posted on my site for
the last lecture.  Load the frmPeopleV3 and notice that the form loads no
data.  Select a company and notice that the data set for the form changes,
likewise the dataset for the cboEmployee.  Both of these objects are
dependent on the cboCompany.  Look in the form's class, particularly OnOpen.
That code is all there is to telling one cbo that other objects depend on
it.

As you can see, I was never proposing "tight coupling" of control classes.
In fact I have to guess that I am actually implementing exactly what you are
envisioning with the collection of dependent objects.  The only difference
is that I have moved the collection and all of the code out into a dependent
object class.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Arthur Fuller
Sent: Saturday, March 13, 2004 3:44 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] ParamArray problem


First of all, why on earth would you want to pass a class? I'm a little
dim but can't imagine a circumstance where that would prove useful. Even
in the factory design pattern, you don't pass an actual class.

While pondering this, I thought for a moment that one approach might be
to create a collection. One cool thing about collections is that the
members need have almost nothing in common. I was thinking about this as
a way around the tight coupling of the dependent objects class that JC
was proposing. I didn't try it, JC, but could that approach work? You
could have a collection of dependent objects, with one "parent" and as
many "children" as depend on that parent. None of the controls would
need to know the name of any other. Just a thought....

Arthur


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
Sent: Thursday, March 11, 2004 5:14 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] ParamArray problem


Sorry, meant to say:

>Indeed you CAN'T dim the array as specific class types AFAICT.

If you look up ParamArrays in help it says that you can type the array
as any of the built-in types including objects, but not custom types
such as classes.

John W. Colby
www.ColbyConsulting.com






More information about the AccessD mailing list