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