[AccessD] Classes and Withevents

[John Colby]

Jim, you have to understand that in the framework and app I wrote I would
instantiate literally thousands of wrapper classes, sink events in those
classes, tear them back down etc.  Thousands every single day for every
single user.  And I didn't have issues.  Shamile got out long before the
last two service packs were issued.

I quite understand that Microsoft isn't actively doing anything with it.
Any remaining bugs will never be fixed.  Yep, got it.  On the other hand by
2005 or whenever SP3 came out, Access was 15 years old and they had been
working on it up to  that time.  It is my opinion that it is remarkably
stable.  It is also my opinion that there is no other DB FE RAD in
existence even close to it in pure data integration and OO integration. It
is a remarkable piece of engineering IMHO.

Maybe I should offer MS a dollar to sell it to me?  :)

>>>There has been very little work done with classes in Access.   Yes, I
know forms and reports in Access are classes, but that's a very different
thing from using classes in VBA.

As for the classes, AFAIK the classes behind reports and forms are the
exact same thing as the classes that you can use if you so desire.  And to
say that little work has been done with them ignores the fact that
everything in Access is a class.  All the controls come from a base control
class.  The DAO engine and everything in it is a class,  AFAICT even the
properties of objects are classes.  All the controls, forms and reports
know how to raise events.

All classes can sink events.  And they can sink events from ANYTHING passed
in to them that is saved "WithEvents".  Every Access developer who uses
event sinks in a form or report class for handling the events from controls
is already sinking events.  It is a miniscule jump to opening your own
class, passing in an object (control for instance), storing a pointer to
that "WithEvents" in the header of that class, and then sinking events from
that control inside of the class you just created.  Trivial.

And... the class itself can raise its own events.  And, any class can take
a pointer to another class, store a pointer to that passed in class
"withevents" and sink the events from that class.  And... anything that can
raise events can be saved in multiple locations and the events sunk in
every class where a pointer to the object is stored "WithEvents".  So a
combo GotFocus event can be sunk in one or a thousand different classes.
Pass a pointer to a combo into a function in the class behind form of 10
other forms, save a pointer to that combo "WithEvents" in the header of
that class, and each of those forms can sink the events from that combo.

And... There are controls at the top of the class which display any objects
saved "WithEvents" in the top of the class, as well as all of the events of
said object.  Selecting such an object and an event will stub out the event
sink for you.

And... all this stuff ALSO works in Excel, Word, Power Point and so forth.

This is precisely the same technology that C# provides.  The syntax for
doing it is different of course but the capability is there.  It is just
that the "average programmer" in Access vba has no clue. But I have a clue.

Access is, from top to bottom, an object oriented design.  At the risk of
repeating myself,  It is a remarkable piece of engineering IMHO.

-- 
John W. Colby
Colby Consulting