[AccessD] DependentObjects class

John W. Colby jwcolby at colbyconsulting.com
Thu Mar 11 09:24:29 CST 2004


Bryan,

Dependent objects say that ComboB is filtered on ComboA.  The NORMAL usage
is when ComboA changes, the data set for Combo will change so we need to
requery ComboB in order to get the new dataset.  The NORMAL usage is that if
we requery ComboB, then because it is probably changing it's dataset, the
object it is displaying is also changing so requery any of ComboB's
dependent objects.  If ComboA is "dependent on" ComboB then we have created
feedback and an endless loop ensues.

In this specific case, ComboA is NOT dependent on ComboB and ComboB is NOT
dependent on ComboA they are just displaying the same potential dataset.  If
ComboA causes the dataset to change then ComboB needs to be requeried so
that it can pick up the changes.  ComboB does NOT need to requery any other
objects however since it did not initiate the changing data. It turns out
that I am using the same functionality for different purposes and that is
really what causes the problem.

I could add a second collection in clsDepObj that holds pointers to any
objects that display the same data but are not dependent in the normal
sense.  Then have another method of the class that says "requery the control
but not the dependent objects".  Call this method for every object in the
SameData collection.  Since only the control / form gets requeried and the
SameData class does not iterate it's dependent collection, we avoid this
problem.

Sometimes it helps to write out the problem like this and solutions start
popping out.  I'll have to think about this one.

Thanks for pointing out the obvious.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Bryan
Carbonnell
Sent: Thursday, March 11, 2004 9:56 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] DependentObjects class


> Obviously if we add combo A to combo B's DependentObject collection
and we
> add Combo B to Combo A's dependent object collection, then we start
an
> endless loop where A requeries B which requeries A which requeries
B...

Maybe Im missing something painfully obvious but.....

Why would you end up with an endless loop?

Here is what I am understanding...

If A is dependant on B and B is dependant on A, they need to be
requeried when the other's value changes.

Since you are adding to A, then the logical assumption is that the
value of A will change to the newly entered value. But B's value won't
change, wil it? The underlying datasource may change, but the actual
value won't. So since Bs value didn't change A won't need to be
requried. Therefore no loop.

Or the other way around:

Since you are adding to B, then the logical assumption is that the
value of B will change to the newly entered value. But A's value won't
change, wil it? The underlying datasource may change, but the actual
value won't. So since As value didn't change B won't need to be
requried. Therefore no loop.

No??

Like I said I may be missing something painfully obvious. It wouldn't
be the first time :-)

Bryan Carbonnell
bryan_carbonnell at cbc.ca

>>> jwcolby at colbyconsulting.com 11-Mar-04 12:11:22 AM >>>
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.

There is a case where two combos on a form may display data from the
same
table.  For example two combos both display cities from the cities
lookup
table.  If Combo A NotInList adds a new city. Combo B needs to requery
in
order to display that new city if necessary.  However if Combo B adds
the
city, then Combo A needs to requery.

Obviously if we add combo A to combo B's DependentObject collection and
we
add Combo B to Combo A's dependent object collection, then we start an
endless loop where A requeries B which requeries A which requeries
B...

This is a case where I programmed a solution working but it was ugly.
How
would you solve this problem?

--
_______________________________________________
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