[AccessD] DependentObjects class

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

In that case, in your custom NotInList event when the data is added why
not do something like this:

'Assumptions - Parent of combo class is a form class 
' and the combo class has a parent property that 
' points to the form class

' All of this is pseudo code

'Loop through all the combo classes in the parent
For each ComboClass in Me.Parent.ComboClasses
  'Check to see if the RowSource of the ComboClass is the 
  ' same as this class' row source
  If ComboClass.RowSource = Me.RowSource then
    'It is, so requery the combo class
    ComboClass.Requery
  End If
Loop

I would think that if you did it this way, then both possibilities (A
dependant on B and A and B share a Row Source) will be covered in the
same class and you don't have to create a separate collection to hold
the row sources.

Just an idea.

>Thanks for pointing out the obvious.

Glad to Help?!?! I think. :)

Bryan Carbonnell
bryan_carbonnell at cbc.ca

>>> jwcolby at colbyconsulting.com 11-Mar-04 10:24:29 AM >>>
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.