[AccessD] Building a control class

jwcolby jwcolby at colbyconsulting.com
Tue Mar 3 14:42:31 CST 2009


 > If the mantra for classes is one class = one object, then a controls class doesn't abide by that.

And that is definitely an objective of class programming.

John W. Colby
www.ColbyConsulting.com


Charlotte Foust wrote:
> I played with that idea some years ago, A.D.  But I could never figure
> out a way to make it actually work in Access.  In .Net, you can cast an
> object as a type in order to use it's type-specific methods and
> properties, but I didn't find an equivalent method in Access VBA back
> then and haven't really looked since.  Also, you'd have to have a HUGE
> class to handle everything, which eventually would become more work that
> modifying a bunch of classes.  So maybe you'd want a Controls class and
> maybe you'd need a GraphicsControls class and a ThirdPartyControls
> class, etc., etc.  It seemed like a great idea when I thought of it, but
> in trying to make it work, I decided I was making more work for myself
> 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
> 



More information about the AccessD mailing list