[AccessD] Classes - A little encouragement

I just wanted to suggest that you look at the times of the lecture emails that I created.  While I 
did cut and paste a little of the code, by and large it was typed into Access from my head, 
compiled, and the lecture created, all in real time.

My point is not to demonstrate how much I know nor how skilled I am, in fact just the opposite.  I 
am good at what I do but I am not any better than any of you.  My point is simply that I understand 
this stuff, and more importantly once YOU understand it, this is how long it will take YOU to do 
these kinds of things.  Most of you can sit down and type in code into an editor, compile and run 
it.  The stuff you already know is just that easy, you just have never learned Classes and Events, 
whereas I have.

You can do this, and you can be doing this in a matter of hours or days.  You can be fluent in this 
in a matter of days or weeks, and once you are, your ability to build complex systems will move to 
an entirely new level.

Hang in there people.  Study this stuff.  Study it now, if not today then this week, this weekend. 
I do not promise that you will be class and event gurus in a day but you can be using them 
comfortably in a few days or weeks.

I will tell you that it takes a little while to convert your thinking to the class paradigm.  I can 
help with that as well.  Think systems, think objects.  I now view classes very similarly to how I 
view normalization of tables.  Because most of you are already comfortable with that normalization 
concept, thinking in class terms can be quite easy.  A class represents an object, in much the same 
way that a table represents an object.  Really the difference is that a table can hold ONLY THE DATA 
about an object, whereas a class can ALSO store the code to make the object come alive.  However 
just like tables, each class needs to represent ONE THING.  We all know that storing data about 
multiple objects in a single table (denormalization) is generally a bad idea.  In the same way, 
using a single class to store data and code about more than one object is generally a bad thing.

Coming from Access we already use and understand objects - controls, forms, recordsets, fields and 
so forth.  In fact EVERYTHING IN ACCESS IS AN OBJECT!!!  We already understand properties of objects 
and methods of objects.  Your own custom written classes are nothing more than objects with 
properties and methods.  Your objects can wrap another object such as a control and give you a place 
to store your own code to turn that combo (for example) into a record selector combo.  To allow a 
form or a control to automatically save changing data into a log file.  Your classes can use other 
classes that you or other people write.  Sometimes systems require two or three objects (classes) to 
implement.

A class is used to encapsulate or wrap up all of the code and variables required to represent that 
object, to store the information about an instance of that object, and to manipulate the data 
however you need to in order to make the object behave as the object needs to behave to accomplish 
your objectives.

I am here to tell you that if I can do this stuff, then so can you.  Yea, I have been doing it for a 
few years now but you will never be able to say that until you have decided to learn it too, and 
more importantly JUST DO IT.

I say it again, it is EASY, you just have to read each lecture, maybe even twice and step through 
the code, and suddenly you too will see how and why this stuff works.

I invite all of you to join this little club I belong to (along with quite a few other list 
members), class users.
-- 
John W. Colby
www.ColbyConsulting.com