[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
> ------------