[AccessD] That useless little thing called Classes - Imagine this

[John Colby]

I am a programmer by training.  I came from Turbo Pascal and Turbe C 
back in the late 80s to VBA (Access) in the early nineties.

I was lost.  Events were popping up without my control.  CHAOS I tell 
you absolute CHAOS.  I was accustomed to a program with menus where 
everything was driven from a user selecting a menu item. Absolutely 
archaic looking back on it and yet I programmed wondrous things using 
that model.  And Events baffled me.

So I learned events and it opened up my world.  But I continues to 
operate without classes until around 1997 when I found AccessD and a 
gentleman named Shamil, our Russian friend.  Shamil was struggling with 
the Access 97 version of Access, and in particular struggling with 
events and the problems they caused back then.

But he banged on me to "learn classes".  I tried but like so many Access 
programmers I "didn't get it".  But Shamil didn't give up. And so I 
eventually learned classes.  And it opened up my world, at an even 
greater scale than events.

You see Events, both sinking and raising, are simply a small part of the 
capability of a bigger concept, the class.  It was when I finally 
embraced that bigger concept that my ability in Access, in PROGRAMMING 
Access multiplied.

I am a "framework" kinda guy.  I had used frameworks from Borland, which 
gave me packages that allowed me to do big tasks without having to 
program every detail of that task.  I used their database framework to 
get databases going without ever really understanding what was going on 
down below.

So once I got my feet on the ground, in the absolute absence of anything 
resembling a framework in Access, I started building my own.  It was 
really just self preservation.

Let me present one very simply example.  I found myself using the Access 
combo to add objects to list tables.  If what the user typed in wasn't 
in the table, the Access combo CLASS OBJECT (remember classes?) raised a 
NotInList event.  What do YOU do with that event?  My guess, if you use 
it all all, you sink that event in the form's CLASS OBJECT and you do 
something REALLY CRUDE like open a recordset right in the form for the 
table which populates that combo, and adding what the user just typed 
in.  Right there in the form.

Or... you do something only slightly less crude like calling a method in 
a library, passing off the name of the table and allow that function in 
a library to do the same thing.

I know the latter is precisely what I used to do.

The class method for doing this is to generate a clsCombo.  Place the 
code to open the recordset in that.  Place the event sinks for the combo 
in that.  Back in the form create an instance of clsCombo and pass in 
the control itself (so we can sink its events) as well as the name of 
the table.

What does all this buy you?  A lot (little bit) of work for what?

One huge thing is that all of the event sinks in the form's CLASS 
INSTANCE / module (that little thing that is so useless because you 
can't inherit a form) suddenly go away.  If I have 20 combos all loaded 
from list tables, I used to have 20 combo NotInList events right in the 
form's CLASS INSTANCE.  Can you say ICK???  Really, all of the events 
for 20 combo's NotInList in my form's class instance?

And why is the form class sinking combo events?  Is the form a combo?  
Is the form 20 combos?  ICK!  A form is supposed to model a form object, 
and it has every need to sink its OWN events, but now it is modelling 
combos and text boxes and who knows what.  ICK!

So I create a combo class, and place all of the code and event sinks 
right in the class.  BTW is this not EXACTLY what you would do in VB.Net 
or C#.Net?  Can you really tell me that you would place all of these 
event sinks in your forms in those environments?  Well you might, not me.

Now what if you also want the combo to automatically drop down as it 
gets the focus?  There is an OnFocus event.  So suddenly you now have 
events for 20 combo's OnFocus in the Form's CLASS INSTANCE. YOUR form 
class is getting damned messy.  What if you want the combo (or text box) 
to change background color to highlight what control has the focus?  Do 
that in the form?????

I place that code out in my combo class.  My form class instance 
(module) is nice and clean.  Not a combo event to be found.  There is 
code to initialize all of my classes up in the form's Open event.

Now, if I want this kind of functionality for a specific combo in any 
form in the project, the code is written and ready.  I instantiate a 
clsCombo (in form open) and initialize it.  Voila, NotInList and 
DropDown and BackGroundColorChange functionality, without cluttering up 
my form module.

My form is not a combo, or twenty combos, it is a form.  It has no 
business routinely sinking every event in the damned world for every 
control I use.  I have looked at forms (my old forms from 1995 for 
example) where there were literally PAGES of event sinks and crap for a 
single form.  Classes made that all go away.

And yes, I can't inherit my class.  So what!

-- 
John W. Colby