[AccessD] Ribbon

[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.

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 occasionally 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 sunk in my clsFrm.

CAUTION... In OOP, one of the foundational ideas is that an object models
one thing.  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... they expect 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 clsFrm.  TBH I didn't even look or think about it.  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.

On Fri, Jan 28, 2022 at 3:36 PM Bill Benson <bensonforums at gmail.com> wrote:

> My method of writing the code into every form using VBE coding is way way
> way easier than all this, since those forms code was already done.
>
> On Fri, Jan 28, 2022 at 10:32 AM John Colby <jwcolby at gmail.com> wrote:
>
> > Sorry, I didn't add myself to the To: of the previous message.  I am
> > answering this way because the previous thread was too long to go through
> > any more.
> >
> > It absolutely is possible to quickly and easily use a class in a form's
> > CBF.
> >
> > 1) Dim the class variable in the header.
> > 2) In the form's OnOpen instantiate the class and sign to the variable
> you
> > just created.  Pass in a pointer to whatever control you want to manage
> to
> > that class instance.  In that class, sink whatever events you want to
> > respond to.
> >
> > What this does is remove the event sinking from the CBF of the form and
> > places said event sinking into the class.  Inside of that class (which I
> > call a "wrapper" class for the gawd awful music they make ;) do whatever
> > you wanted that control to do.  Turn on and off the toolbar or whatever
> ...
> >
> > Copy and paste the code you just created in this CBF into every other
> > form's CBF.
> >
> > I haven't been following this thread closely.  I am just responding
> really
> > to the comment "classes are for controls, not forms.  NOT the case.  They
> > are for both.
> >
> > seadvisors.com <http://www.databaseadvisors.com>
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


-- 
John W. Colby
Colby Consulting