[AccessD] Building a control class

Stuart

 > But a control  *is* an Object. It's also a Class with it's own set of properties and methods.

It is indeed an object.  As I have said many times, EVERYTHING in Access is an object.  A specific 
type of control is a subclass of a generic control object.  It inherits all of the control class 
properties and adds its own properties, methods and events.  Unfortunately while the Microsoft 
developers of Access have control at the inheritance level, we do not.

However even in .Net you would usually start with the lowest (down the tree) object that represents 
what you are modeling and go from there.  We are building wrappers in a poor man's attempt to add 
functionality to some specific thing, a combo, or a text box or a tab control etc.  We are 
"modeling" a descendant of the object we are wrapping and adding functionality to that object.

You absolutely could wrap an untyped control, but then you are modeling a descendant of the untyped 
control object.  You do not get the properties, methods and events of a combo or a radio button for 
example.

If you choose to attempt to do this (and you want to sink events), you WILL end up with a 
dimensioned variable TYPED for each control type that your single class is modeling.  IOW there will 
be a combo variable dimensioned WithEvents.  Likewise a text box, tab control, command button, radio 
button, group, etc.  So you will have about NINE variables in the header of the class each 
dimensioned WithEvents.  Only one will be used for any class instance.

NOW... you will have all of the event sinks for NINE different controls, and the code that goes in 
all of those event sinks.  Yes, some may be the same code but some may not.  For instance in my 
framework, the dbl-click of the combo CAN open a form to edit the list behind the combo.  Do you 
want your dbl-click of the text box doing that?  There is no list for the text box!

I am not going to get into an argument about this.  We each get to make our own decisions as to the 
wisdom of how we do things.  Trying to use a class to simultaneously model a combo and a text box 
and a command button and a tab control, a radio button and a group etc is not IMHO a wise thing to 
do.  Yes, these are all controls but they are radically different in how they operate and what we 
use them for in a form or report.

If any list member wishes to use one big control class feel free, and please do report back on how 
doing that affected your programming effort.

John W. Colby
www.ColbyConsulting.com


Stuart McLachlan wrote:
> 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