[AccessD] Classes and withevents

Jim Dettman jimdettman at verizon.net
Sun Aug 30 11:48:13 CDT 2020


<< As for errors locking up the app, Shamil taught me this stuff.  He
largely
abandoned trying to make it work because of the problems he ran into.  I
believe that MS got the kinks worked out.  >>

  FWIW,  I would not count on that.

   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.   VBA itself has gotten very little love
from Microsoft for a very long time now and it's highly doubtful it would
moving forward.    It's just not where their focus is.   Even to this day
there remains a number of long-standing issues that they show no signs or
interest in fixing.   

   Of course there are practices you can follow to minimize internal bugs
with Access/VBA (i.e. closing objects, setting things to nothing, being
fully explicit, etc), but don't expect anything that's been there before to
work any differently, and there is a high probability that you could run
into something that would not be fixed.

 Like I said, FWIW.

Jim.

-----Original Message-----
From: AccessD On Behalf Of John Colby
Sent: Saturday, August 29, 2020 11:17 PM
To: Access Developers discussion and problem solving
<accessd at databaseadvisors.com>
Subject: Re: [AccessD] Classes and withevents

I'm in an interesting position.  I developed my framework largely during
the development of the Disability Insurance call center software.  Before
that I really didn't "get" classes and so I used collections of collections
to do some of the stuff I later did with classes.  Very crude.

At any rate I retrofitted my billing app to use the framework as I switched
to hard core class / events.  At the end I had a client for whom I was
doing SQL Server stuff.  I literally built the servers from parts and they
were quite powerful for the times - 16 cores on two cpu chips, 90 gigs of
ram, raid6 etc.  So I ported my billing database to live on that server.
In the end the server lived in a hosting site in NY and I lived in NC.  But
the billing app was quite happy to work across the internet,

Well... that business eventually died and I got the servers back.  They are
turned off in the other room.  So my latest billing data and "back end" sit
on a turned off server in my spare bedroom, on what is now "dated"
hardware.  If I want to resurrect my billing database I need to turn the
server back on, back up my billing database, get a sql server running on my
laptop and make it serve my billing BE.  Worth doing I suppose but a lot of
work.

As for errors locking up the app, Shamil taught me this stuff.  He largely
abandoned trying to make it work because of the problems he ran into.  I
believe that MS got the kinks worked out.  I did not run into any such
issues, although it is critical to understand how to instantiate, and
equally importantly, tear down the classes consistently and reliably.  I
believe a lot of the early problems were events being hooked and never
released.  Access' garbage collector only collects the garbage once the
last pointer to objects are removed.  I learned to rigorously perform
teardown in the parent class' OnClose.  Any pointers to objects are
released there.

And I pushed this stuff way beyond what anyone other than perhaps yourself
ever did.  In the end my call center app worked very smoothly.  Classes
allow the developer to build a consistent interface that works the same way
everywhere, one place to fix a given bug, all those benes we understand
so well.

You and I should start a school.  If Access is going to refuse to die, the
least we can do is support its OOP.  :~)



On Sat, Aug 29, 2020 at 7:10 PM Charlotte Foust <charlotte.foust at gmail.com>
wrote:

> I used them in the same way, John.  Maybe someone will pick up something
> useful from your code.
>
> Charlotte Foust
> (916) 206-4336
>
>
> On Fri, Aug 28, 2020 at 11:19 AM John Colby <jwcolby at gmail.com> wrote:
>
> > 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
> > --
> > 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
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list