[AccessD] Doing some thing the class way... was Toolbar

[John Colby]

Bill, I am in no way dissing your answer, your experience, or point of view
- in fact I highly respect all of the above.

The original author asked if it could be done in a class called from each
form that wanted to do this.  Seems like that is worthy of asking, worthy
of consideration.

There are more ways to kill a cat than choking it to death on butter as my
mamma used to say.  Sometimes quick is good or even best.  I wasn't even
really addressing the original thread since I wasn't following it closely.
I was addressing the concepts.

I understand quite well that to the majority of Access developers what I do
with classes is, shall we say, not understood well, if even at all.  I try
occasionally to poke ideas into conversations just to stimulate thinking
about how we do things. So...

Frameworks are everywhere.  In the 80s I learned to program in Turbo
Pascal, whereupon I stumbled on their database framework.  It was a SYSTEM
of code which allowed me to use a database for Turbo Pascal.  From that
experience and others a little later grew my passion for creating my own
framework for Access, office and VBA.

Using a class to wrap a form is the foundation for a framework.  Using a
class to wrap each control is another piece of that framework.  I wrote
every single piece of my framework as code behind form, calling functions
in a library of functions, because where else does code go?

It didn't take long to discover that I was coding a concept over and over
in many of my forms.  And my CBF was looooonnnnnnngggggg.  Out the door and
down the hall loooonnnnnnnggggg..... because I was sinking events in each
form, doing exactly the same thing in form A as in form B.  Except I was
embedding the event sinks to do that in each form.  Identical code,
everywhere.  A maintenance nightmare.  And I ran square into that
maintenance nightmare myself.

When I discovered classes and the fact that I could write a clsFrm, wrap my
form with my clsFrom and then sink form events into that clsFrm, all of a
sudden all of those event sinks in all those CBF modules doing exactly the
same thing went away.  Any code that was used everywhere went into my
clsFrm and those events that used to be sunk in the CBF of all those forms
was now sunk in my clsFrm.  Except that I was still sinking events for
other objects directly in my clsFrm.  IOW modeling more than one thing in
my class.

CAUTION... In OOP, one of the foundational ideas is that an object models
one thing (or a system).  A clsFrm models a form, a clsCbo models a combo
box etc.  If I think about the CBF module behind a form, it is instantly
obvious that I am writing a class which models a form, AND EVERY combo,
text box, radio button etc placed onto that form.  NOT GOOD!!!

Convenient yes.  It allows us as nube programmers to get our feet wet
writing event sinks, to learn event driven programming, to learn about the
dozens of events for the dozens of controls, but hey... what a friggin mess
we make as a result.  Microsoft did us all a favor with the CBF module
behind forms, making all that "event sinking" stuff easy precisely so that
we would learn it.  But... MSFT expects us to learn that stuff and then
think about moving on.

It isn't like I never did that CBF thing, I did!  For the first 10 years,
the entire decade of the nineties I did exactly that.  Forms with dozens of
controls embedded in them, with any events for any of those controls sunk
directly in the CBF class module.  Code out the door and down the hall in
every form.  There is a better way.

Not a faster way, not more convenient in any given situation, not even
appropriate in every given situation, but fundamentally better from an OOP
perspective.   If the same code is in events in many forms, move those
events into a clsFrm and have them written in one place.  Reference the
class in the CBF and pass in a pointer to the form.  Sink those events in
clsFrm now.  Voila, all that repetitive code in all those CBF modules is
gone.  Which makes my code much more readable, much more maintainable.

We can have a conversation about frameworks if we want.  We can discuss how
it is done, why it is good, when it is and isn't useful.  What we can't do
is discuss is how doing xyz is always better, because that isn't true.

In this specific case, the toolbar thingie, it may not even work to try and
do it from a class.  TBH I didn't even look or think about it.  I was
addressing "can it be done" not "is that the best way".

-- 
John W. Colby
Colby Consulting