[AccessD] Standard vs. Class Module

MessageAs a big believer in classes (but a poor doer) I've tried to move in that direction for years.

I've recently been working behind a class fiend in a VB project and have had a chance to
do more classes.

Here's a "BIG" reason to use classes for those who're having Senior moments - lookup.  I've
accumulated hundreds of functions over the years and occasionally find myself redoing something
I've had for years just because I can't find it.  If you can remember the class name, you can lookup 
the variable.  I intend to head in this direction soon - except for ...

   ... Access Add Ins - Can't directly use a class in an Add In module.  I think you could move 
your class to a VB project and make a Dll and be able to use it directly that way - will try someday.  
If anybody knows let me know.

Tom (uh, uh, uh ... oh yea) Adams


  ----- Original Message ----- 
  From: Drew Wutka 
  To: 'accessd at databaseadvisors.com' 
  Sent: Monday, February 03, 2003 6:55 PM
  Subject: RE: [AccessD] Standard vs. Class Module


  Hmmmm.....good question.  

  Let's start with the basics.  A standard module is a flat code page.  It can house code, store global variables, and can house callback functions.  The main portion of that is it can house code.  You can put all of the functions and subs within it that you would like, however, that is all they are, functions and subs, and thus a standard module is relatively 'unorganized'.

  A Class module is a code 'object'.  Being an object allows the Class module to have properties and procedures.  The code within is the same (language wise), but now you have an organized set of code.

  Examples where a Standard Module is useful.

  modOSMachineName

  That's the name of a module I have which gives you the name of the computer you are on.  It's a simple API call.

  modOSUserName

  Same as above, but it provides the NT Username of the person logged onto a computer.

  Can these be put into a class?  Yes they can.  However, they are just as organized in their own modules.  Putting them into a class would be useful as a 'Environment' object:

  Dim env as Environment
  set env = New Environment
  debug.print env.MachineName
  debug.print env.UserName

  However, if you just want the computer name, here and there, instead of creating a class object, just to use one property, then it would be better as it's own function in a module:

  debug.print fOSMachineName

  Examples where a Class Module is better:

  This list would be huge, because when you really dig into Class modules, you will find that they are so much nicer to use.  However, I have a specific one that I would have liked to use back when I was doing heavy Access FE development.

  Way back when, I liked to control the 'toggle' keys on the keyboard.  (Numlock, CapsLock and ScrollLock).  What I used to do, was have a module that had a function to set a toggle key oneway or the other, and another function to just 'check' the state.  What I should have done, is create a Keyboard Class, or Toggle class, and have that class 'represent' the toggle keys on the keyboard.  That way I would be able to 'control' the keyboard toggles as an object, instead of using multiple functions.

  Drew


    -----Original Message-----
    From: Myke Myers [mailto:mmmtbig at bellsouth.net]
    Sent: Monday, February 03, 2003 5:44 PM
    To: accessd at databaseadvisors.com
    Subject: [AccessD] Standard vs. Class Module


    Can anyone describe how to determine when to use a standard module and when to use a class module in Access?

    TIA    Myke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://databaseadvisors.com/pipermail/accessd/attachments/20030204/d35e8ab7/attachment-0002.html>