Arthur Fuller
artful at rogers.com
Mon Mar 15 14:04:01 CST 2004
Good answer(s). Now I want to push the envelope a bit, and ensure that the framework can handle it.... On a given form I have N checkboxes or option buttons or whatever. Beside these (some subset of all the controls), I have a DateUpdated field -- classic case of Dependent Object. But I want more than that. I want to write to a table ValuesChanged, automatically (i.e. class behaviour), sending the table name, the field name, the userID and the dateTime. And have this happen as a simple result of changing said control. Arthur -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby Sent: Friday, March 12, 2004 2:11 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] DependentObjects class >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 -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com