[AccessD] Classes and withevents

[Charlotte Foust]

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
>