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