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