[AccessD] Classes and withevents

John Colby jwcolby at gmail.com
Fri Aug 28 13:18:56 CDT 2020


As for me, I discovered classes about midway through my career in Access.
They do not have inheritance, but they do provide encapsulation of code nd
data and they can sink events from any Access object that raises events,
and can themselves raise events.  Everything in Access is a class.  Every
control, every form, every recordset everything.  All controls and the
forms raise events.

Yes you can hook the events in the form's class via the form's property
sheet but that is truly kludgy. Essentially the form's class is now tasked
with being an event sink for control objects.  If you have one or a dozen
combo boxes and you want to hook the events, all those event sinks are held
in the form's class.  OnEnter, OnExit, OnClick, etc etc, event sinks for
non-form objects sunk in a form class.

I discovered how to make what I called "wrapper classes", i.e. classes
which "wrap" an object like a text box, a list, box, a  combo box, a radio
button etc.  You name it, I had a wrapper class for that control.  I
actually wrote a form class which would scan the form as it instantiated
looking for controls, and when found I would "wrap" the control in it's own
class.  These classes then had event sinks for every control event that I
cared to handle.  So if there were (for example) a dozen text boxes, the
control scanner would find each text box, instantiated a text vox class,
pass in the pointer to that specific text box, and save it "withevents" in
the header of the class.  At that point, that class could sink any and all
events for that one text box.

I would then store every control class created by the form class' control
scanner code in the form "wrapper class" which had a collection to store
pointers to the control classes.

Given this framework, instantiating  a form wrapper class would find and
initialize all controls on any form.  Voila, done.  It would likewise tear
it all down when the form closed.

I used this for things like...

In a form, I wanted a standard back ground color for controls.  But how do
you inform the user which control has the focus?  You sink the OnEnter
andGotFocus events in the control's wrapper class.  As a control gets the
focus, the event is sunk in the wrapper class, which then stores the
current color, and changes the background color to something else.
Whatever control has the focus now "automatically" changes color as it gets
the focus (or onEnter) and switches the color bask as it loses focus (or
onExit).  All automatically.  The code is written once when I designed the
wrapper class, and now it "just works", every time, every where, every
form, every control on every form.

Another example.  I wanted combos to be able to open a form to edit the
data displayed in the combo.  If the combo is loaded from a table, then a
Double click would open a form to allow the user to add, edit, or delete
the data in that table.  When that form closed, the combo needs to requery
itself.  How do you do that you ask?

The combo "wrapper class" has all the code to do that.  The onClick event
discovers which table the data is coming from and opens the form for
editing that table.  As the edit form closes, the combo wrapper class
requeries the combo.  All automatically, every time, every where.  Class
wrapper code written once, then it "just works"  Every combo is discovered
by the form clss' Control scanner and "wrapped" in a class which handles
all that.  As well as the aforementioned background color stuff.

Classes, and event sinks for controls are waaaay powerful stuff.  Nope, I
couldn't inherit the control, but I could "wrap" the control in a class
which sank it's events and performed whatever processing, whatever behavior
I, the UI interface designer decides was useful.

And that stuff is what is contained in the examples I pushed to GIt.

On Fri, Aug 28, 2020 at 12:41 PM Charlotte Foust <charlotte.foust at gmail.com>
wrote:

> When I was active, I used classes and withevents in pretty much every
> application.  Now I'm involuntarily retired, but I think a lot of newer
> developers never learn the power of classes.  There was also always the
> downside that an error could break the entire application and leave a user
> frozen in place.  For those of us who liked pushing Access to its limits,
> classes were great!
>
> Charlotte Foust
> (916) 206-4336
>
>
> On Fri, Aug 28, 2020 at 6:50 AM John Colby <jwcolby at gmail.com> wrote:
>
> > Of those still doing access development, do you you use classes and if so
> > how?
> >
> > Do you use event sinking and sourcing in classes and if so how?
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


-- 
John W. Colby
Colby Consulting


More information about the AccessD mailing list