Stuart McLachlan
stuart at lexacorp.com.pg
Tue Mar 3 14:40:26 CST 2009
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