[AccessD] DependentObjects class

John W. Colby jwcolby at colbyconsulting.com
Fri Mar 12 16:11:13 CST 2004


>Instead, they recommend creating a class that holds both controls as
attributes of the class. This may or may not work in VBA, of
course.

And of course that can be done.  However since the framework exists (or
will!) and it has a combo class, why not allow any combo to know that
something else is dependent on it, and then when it changes go requery
anything that is dependent?

In addition, in many cases where I have seen this sort of "one combo depends
on another's value" thing done, it is IMO frequently the result of bad
design at the database level.

Yes, but you intentionally chose an example of normalization issues.  What
about companies  / people / employees?  As you select a different company in
ComboA you want the "choice" of Employees in ComboB to change?  What about
Companies / payments, companies / invoices, companies...

Dependent combos is SO common that it is a frequent "how do I" topic on this
very list.

>So in that case we're back to the custom class that embeds both combos.

Absolutely possible and in fact easy using classes and Withevents.  But
again, all I have to do is tell the class instance for ComboA that ComboA
"is dependent on it" and then whenever ComboA changes it automatically
requeries ComboB.  If comboC is dependent on ComboB, then when ComboB is
requeried by ComboA, ComboB looks in it's dependent objects collection (or
class) and requeries all of ITs dependent objects.  This is a classic case
of a normal framework behavior replacing custom programming.

>But I do believe that designing classes that know specifics about other
classes (i.e. worst of all is that they must know the name of the other
class's instance) is fundamentally incorrect.

The class doesn't know anything except it has a collection of objects that
it needs to requery!!!  No clue at all what the objects are, just that they
are in its collection and it needs to call a requery method for each one.
In fact the objects can be other combos, other lists, subforms, other open
forms... anything in the application that is a class and as a requery
method.  The DEVELOPER knows that ComboB depends on ComboA and in the form's
Open event tells the framework (a specific class instance).

Further combos aren't the only objects that can have dependent objects.
Basically anything (any control) that can be referenced by the SQL of
another control can have dependent objects.  A text box can be referenced by
a combo so it can have a dependent objects class.  Likewise a checkbox, a
radio button, ANYTHING that can be referenced by SQL in the recordset for a
control or form.

Stick around for the discussion, we are about to add that functionality to
our "framework" (it isn't a framework yet!) so you can see what I am talking
about.

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: Friday, March 12, 2004 1:49 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] DependentObjects class


Further, in the O-O courses that I have taken this kind of thing is
specifically discouraged because it tightly couples the controls.
Instead, they recommend creating creating a class that holds both
controls as attributes of the class. This may or may not work in VBA, of
course.

In addition, in many cases where I have seen this sort of "one combo
depends on another's value" thing done, it is IMO frequently the result
of bad design at the database level. For example, a table contains say
State and City fields, populated from the tables States and Cities --
and then the UI filters the Cities field on the basis of the State
selection: bad design, IMO. There's no need to store the State, since we
have the city, and New York exists in only one state.

On the other hand, take the case of ProductCategories and Products. At
the database level, IMO, the same pertains: do not store the category
since it can be inferred from the product. However, it may well be
useful for the user to select a category and then a product from said
category.

So in that case we're back to the custom class that embeds both combos.
I don't know if that approach can work in Access. I leave that to JC to
determine. But I do believe that designing classes that know specifics
about other classes (i.e. worst of all is that they must know the name
of the other class's instance) is fundamentally incorrect.

Just my $.02
Arthur

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart
McLachlan
Sent: Wednesday, March 10, 2004 9:40 PM
To: Access Developers discussion and problemsolving
Subject: Re: [AccessD] DependentObjects class


On 11 Mar 2004 at 0:11, John W. Colby wrote:

> I am working on a dependentobjects class, i.e. a class with a
> collection which holds objects (classes) where the control or form is
> dependent on the current control.  Combo A changes.  Combo B uses
> Combo A to filter itself. Combo B is "dependent" on combo A and must
> be requeried whenever Combo A changes.
>
> This is a case where I programmed a solution working but it was ugly.

> How would you solve this problem?
>

I doubt if I would do it with a class.

It's not *that* common a requirement and there are so many different
ways that you can end up with circular references,  CtlA - CtlB -
CtlC - CtlD...... CtlX - CtlC   etc  that trying to allow for them
would end up with such code bolat that the whole thing became
inefficient.








--
Lexacorp Ltd
http://www.lexacorp.com.pg
Information Technology Consultancy, Software Development,System
Support.



--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com






More information about the AccessD mailing list