JWColby
jwcolby at colbyconsulting.com
Fri Mar 16 08:48:31 CDT 2007
Now William... ;-)
I am a programmer at heart, long before I learned databases I was writing
code. I remember how cool it was when I found the Borland database toolbox
to accent my Turbo Pascal abilities - prewritten code for doing all the
database stuff without having to DO the database stuff (in code). Now I
have Access which does the database stuff for me. True, I learned the
fundamentals of database design as I never did back in the "pure coding"
days, but I am still a "database analyst / PROGRAMMER" (emphasis mine ;-).
To learn VBA and write programs of any complexity and ignore classes is,
well... Kinda like learning to drive and then ignoring the brakes. You can
get there but the results might get a little ugly.
Classes are dead simple to learn the basics of. I am going to give a real
life example of something that is sooooo useful, soooooo easy, and soooooo
difficult (or at least messy) to do without classes. PLEASE don't think
this is a flight into the nether world, it is not, it is EASY!
We all would like to be able to time a query running, a report opening, a
form opening, things like that.
I have a timer class which I am going to walk you through creating and
using.
1) In Access go to the database window.
2) In the menu bar select Insert / Class Module
3) Cut and paste the code BETWEEN the asterisk line into the new module.
4) You may get a duplicate OPTION line, delete the duplicate.
5) Compile to make sure that you have no issues.
6) Save as clsTimer
7) Instructions continue below the class code...
'******ASTERISK LINE
Option Compare Database
Option Explicit
'
'This class is so simple that I will not use the normal class framework
interface.
'This class never loads children, never does anything that should cause
problems
'so the framework interface is generally unneeded.
'
Private Declare Function apiGetTime Lib "winmm.dll" _
Alias "timeGetTime" () As Long
Private lngStartTime As Long
Private Sub Class_Initialize()
StartTimer
End Sub
'THESE FUNCTIONS / SUBS ARE USED TO IMPLEMENT CLASS FUNCTIONALITY
'*+Class function / sub declaration
Function EndTimer()
EndTimer = apiGetTime() - lngStartTime
End Function
Sub StartTimer()
lngStartTime = apiGetTime()
End Sub
'*-Class function / sub declaration
'******ASTERISK LINE
8) In any code where you need to time something DIM and SET a timer class
instance.
Dim lclsTimer as clsTimer
Set lclsTimer = new clsTimer
9) The timer is running. Place the code you wish to time after the SET
statement.
While MyVar <= SomeOtherVar
Do something I want to time
Wend
debug.print lclstimer.EndTimer
10) You can continue to use that same timer class if you wish...
lclsTimer.StartTimer
While SomeVar <= SomethingElseEntirely
Do something else you want to time
wend
debug.print lclsTimer.EndTimer
You have just used a class. How hard is that? Now, WHY would you use a
class for this? ENCAPSULATION!!! Encapsulation is the process of storing
everything required to perform the function on one place, as a unit. You
are "encapsulating" a timer inside of a class.
Anyone around long enough would recognize this code as coming from the gods
of Access - Ken Getz et al from their handbook. BUT the biggest difference
is that Ken's version has a simple global variable. It worked but what
could you NOT DO? Use it more than once "at the same time", BECAaaauuuus...
It uses a global variable. Thus if you start another timer over there, it
would overwrite the time value for the instance you started over here.
With a class I can instantiate 1 or a thousand of these timers and EACH
INSTANCE has its own timer storage variable safely encapsulated in its own
class header.
Dim lclsTimer1 as clsTimer
Dim lclsTimer2 as clsTimer
.
.
.
Dim lclsTimer999 as clsTimer
There you go, 999 DIFFERENT timers all happily timing their own pieces of
your code, measuring various forms opening, reports opening, while loops
whiling.
Can you do this without classes? Yea but it ain't pretty.
How about using a static variable inside of the function and then cutting
and pasting the code, changing the names all the time (kinda like another
lister does with his filter functions). YUK!!!
How about using a collection to store the timer value? That works, create a
STATIC collection inside of the timer function and pass in the NAME of the
timer, inserting the time value into the collection keyed on the name? It
works, but is it clean and simple? You have all this stuff to get the time
value, if you are reading the time, write the time value if you are starting
the timer etc. YUKKK!
The class on the other hand is clean and simple. Named something intuitive,
all the code and the time variable contained right in the class, easy to dim
and start, easy to read, easy to restart...
Classes are not the enemy, they are a TREMENDOUSLY powerful tool for solving
problems that can be solved in other ways but which when a class is used
makes the whole thing soooo much simpler.
There IS ONE DOWNSIDE to classes... Once you use them your programming
changes. Slowly, over time, half (or more) of your code is going in classes
and your classes are using other classes using other classes. Your program
becomes more powerful, and listers start to poke fun at you about your
speaking in greek like c++ programmers on other lists.
;-)
I truly don't mind though, cause I got classes! ;-)
John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman
Sent: Thursday, March 15, 2007 10:41 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Naming Conventions
...and then there are those of us who's head spins when JC starts thumpin'
...those who just manage to make it work without rebuilding the Pyrimids
first ...I admire what JC does and I've learned more than a few things from
him over the years that are part of my standard library ...but holy cow,
trust me, it is still possible to build good, sound, responsive apps fairly
rapidly without selling your first born child to the gods of Access :)
...so if any of you lurkers out there are thinking how much JC's posts sound
like those you find over on the C++ forums, don't despair ...he does come
down to earth often enough to enlighten even those of us who need a
dictionary to translate his occasional flights into the nether world :)
William Hindman