[AccessD] Standard vs. Class Module

MessageAs I have mentioned numerous times, I use a framework for my FEs.
This framework runs the app pretty much, or at least runs the form
presentation side of things.  It is not a trivial application, all in
itself.  As a result I have a class that does nothing but initialize the
framework!  As would be expected, this class only ever loads once (in a
given project) but that class holds data structures and methods that are
global to the class, initializes my system variables, initializes the
application variables etc etc.  Thus with a simple:

dim gclsFW as clsFW my framework springs to life and does everything it
needs to do to get things going.  Then other code can use gclsFW.XXXX to
access methods and properties that they need to read sysvars etc.
John W. Colby
Colby Consulting
www.ColbyConsulting.com

  -----Original Message-----
  From: accessd-admin at databaseadvisors.com
[mailto:accessd-admin at databaseadvisors.com]On Behalf Of Jim DeMarco
  Sent: Wednesday, February 05, 2003 9:01 AM
  To: accessd at databaseadvisors.com
  Subject: RE: [AccessD] Standard vs. Class Module


  No clear cut answer to this question.  I normally put any code that I feel
I will reuse in a class module (by reuse I mean within the same app only, or
many apps).  A couple of examples:

  1. I used to have a problem remembering the provider/connect string for
Access and SQL OLEDB provides used when opening an ADO connection and/or
recordset(s).  I wrapped the code I use to open connections and create
recordsets in a class, cDatabase.  Now when I want to use ADO I create an
object of type cDatabase, call the OpenConnection method, pass in the mdb or
SQL DB, and pass a parameter telling the class what type of db I'm using and
I've got my connection.
  Ex.
  <snip>
  Dim oDB As cDatabase
  Dim rs As ADODB.Recordset
      Set oDB = New cDatabase
      oDB.OpenConnection "mydb.mdb" 'mdb is default so we don't have to pass
optional db type argument
      Set rs = oDB.OpenRecordset ("mytablequeryorsql")
  </snip>
  I don't have to remember or find the provider/connect string anymore.

  2. I wrote some code that reads setup/configuration settings from an XML
file.  Once it was done I realized I'd like to add this functionality to
more apps so I ported it into a class module.  Now with no knowledge of XML
my team of developers can add this functionality to their apps by importing
the class module.

  This is not to say a one-off class is not out of the realm of possibility.
As J. Colby mentioned in a earlier post, if you need certain functionality
in more than one place in a single app classes make it very easy to add that
functionality without copy/paste or reviewing a code module to see "how it
works" or how to use it.

  We all have stand alone functions that belong in standard modules.  One
common module (here at least) is basUtil containing utility functions like
IsLoaded to check whether a form or Access object is currently open (things
not related to the function of the system).  There's nothing stopping you
from putting those in a class.  Why bother?  Class objects implement type
ahead code functionality.  Imagine then how easy it would be to access your
utility functions by calling an object of type cUtil as follows:
  <snip>
  Dim oUtil As cUtil
    Set oUtil = New cUtil
    oUtil.IsLoaded "myform"
  </snip>
  I'd normally have to take a look at basUtil to see what functionality was
in there but the class object's type ahead would alleviate that (actually,
this was a last minute thought but I think I'll give it a try!).
  HTH,

  Jim DeMarco
  Director of Product Development
  HealthSource/Hudson Health Plan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://databaseadvisors.com/pipermail/accessd/attachments/20030205/90e6f4ee/attachment-0002.html>