Charlotte Foust
cfoust at infostatsystems.com
Tue Mar 3 15:05:41 CST 2009
Of course it's an object, but it's a generic object in a collection of generic objects. What does a control look like? A textbox is a control but a control isn't automatically a textbox. So what are you going to do, give the control class every method and property there is and just go "oops!" when one of them doesn't apply? Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan Sent: Tuesday, March 03, 2009 12:40 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Building a control class But a control *is* an Object. It's also a Class with it's own set of properties and methods. Otherwise you couldn't do: For each ctl in me.controls ...... Next On 3 Mar 2009 at 11:13, Charlotte Foust wrote: > rather than less. If the mantra for classes is one class = one > object, then a controls class doesn't abide by that. > > Charlotte Foust > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of A.D.Tejpal > Sent: Tuesday, March 03, 2009 10:54 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Building a control class > > John, > > What I have in mind is a generic class, that morphs into a > dedicated type as per the control passed to it. For example, if a text > box is passed as argument, it acts as pure text box class. Similarly, > for a combo box, it functions as pure combo box class. > > No doubt, the code content for such a class is more than that in > tailor made class for single control. However, it offers the advantage > of a common place to manage the code. Duplication of certain content > across multitude of classes can be avoided. If any common improvement > / enhancement in class code is found necessary, it can be done > conveniently at one place. No need to edit all the scattered classes > for individual controls. > > Best wishes, > A.D. Tejpal > ------------ > > ----- Original Message ----- > From: jwcolby > To: Access Developers discussion and problem solving > Sent: Tuesday, March 03, 2009 18:54 > Subject: Re: [AccessD] Building a control class > > > A.D. > > >If a single class covering all controls (complete with events) > were to be devised, could there be any reason not to prefer it over a > host of classes control-wise? > > Unfortunately a generic control object cannot be dimensioned > WithEvents, which is what is required in order to be able to sink the > events for a control. > > If you think about it, each control can have completely different > events. Take the combo control for example, it can raise a NotInList > event. The only other control that has this event is the list control. > The data controls have dirty, undo and change events whereas the > command button does not. > > So, you cannot pass in a control object (as opposed to a textbox > object or a combo object or a command button object) and then save it > to a control object variable WithEvents. So you cannot sink the > events inside of the class. > > Aside from that there are indeed good reasons to have a class for > each object. A class is supposed to model an object. A command > button is not a combo. A tab page is not a text box. Each of these > things has specific things that you need to handle. The combo is > going to have a NotInList which you will need to sink and run code > for. A text box may want to drill down to discover its bound field > data type so that it can set a specific date format (just an example), > whereas a tab page will not need that. > > So if you did try to create a single generic control class (and > could somehow sink > the events) you would still end up with code and variables for a > mish-mash of objects, and your class would become a nightmare. A text > box may want to build an audit trail system whereas a command button > wouldn't. > > You would not create a single class to represent a bank, account, > customer and check, even though they are all parts of a bank system. > Aside from the event sink quandary, controls are simply too different > to model them all in one class. > > >While assigning "[Event Procedure]" to various events, it seems > desirable to make it conditional to the event not already having been > assigned some function (e.g. =MyFunction()) as otherwise the latter > stands suppressed. > > That is true. OTOH, once you start building a true framework where > the form class scans for controls and automatically assign classes to > the controls, you are going to want to find and at least discover what > these MyFunction() thingies do. Probably you will want to migrate > their functionality into the control classes. > > I have an ideological resistance to using that =MyFunction() method > of hooking events. My problem with the method is that is almost > impossible to discover what control uses MyFunction() without a search > and replace program. Even with said program how do you discover every > event in the program hooked in such a manner? It is a maintenance > nightmare. By using a class for each control, you can place all such > functions directly in the class, build the event sinks to call the > functions in the class, and have a single place to go to maintain all that code. > > If you are going to work in a system that contains such event hooks, > you will probably have to write code to open every form, scan all of > it's events, then scan every control on each form checking all of > their events specifically looking for such hooks and recording them in > a table for cleanup. > > One of the objectives of a framework is to have a consistent user > interface across the application. While MyFunction() might accomplish > some specific piece of the interface precisely as intended, as you > move to a framework it becomes tough to extend the interface since you > expect your control classes to provide the functionality. The form > class control scanner will automatically find and hook events, whereas > the > MyFunction() method depends on the developer remembering to do that. > If a new developer comes in (s)he may not even know to go hook up all > of the events as (s) adds a control to the form. > > John W. Colby > www.ColbyConsulting.com > > > A.D.Tejpal wrote: > > > John, > > > > If a single class covering all controls (complete with events) > were to be devised, could there be any reason not to prefer it over a > host of classes control-wise ? > > > > While assigning "[Event Procedure]" to various events, it seems > desirable to make it conditional to the event not already having been > assigned some function (e.g. =MyFunction()) as otherwise the latter > stands suppressed. > > > > Best wishes, > > A.D. Tejpal > > ------------ > -- > 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