[AccessD] Building a control class

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

  If VBA had full inheritance, then you could do that.  But since it does
not, you can't truly build a class hierarchy such as this.

  A good example of what your thinking might be a date only control.  Really
it's a text control that only allows dates to entered.  If VBA really had
inheritance, then you would have your class of TextControl, which you'd
inherit and override to get the date only behavior. 

  I've worked in VFP for a few years now and everything in VFP is built on
top of base classes.  In fact, for the framework I use, it breaks out like
this:

VFP Base Classes
   VMP Base Classes (framework that I use)
      OCS Base Classes (my classes)
         App specific classes.

  So if I want to change the way a text control works in every application
that I write (say to add a security feature), then I change the OCS base
classes.  Every app then gets the behavior.

Jim.

-----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 1:54 PM
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