Charlotte Foust
cfoust at infostatsystems.com
Fri Mar 12 10:33:49 CST 2004
Unfortunately, some city names get recycled among states, Arthur. Witness Kansas City, Kansas, and Kansas City, Missouri. There is no guarantee that the city defines the state. The same is true of counties and other location names. There certainly are a few unique city names, but that isn't enough to form the basis of a design. Charlotte Foust -----Original Message----- From: Arthur Fuller [mailto:artful at rogers.com] Sent: Friday, March 12, 2004 10:49 AM 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