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