[AccessD] Building a control class

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