Jim DeMarco
Jdemarco at hshhp.org
Wed Feb 5 11:51:01 CST 2003
Sent early AM and so sign of this one. 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 -----Original Message----- From: Myke Myers [mailto:mmmtbig at bellsouth.net] Sent: Monday, February 03, 2003 6: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 *********************************************************************************** "This electronic message is intended to be for the use only of the named recipient, and may contain information from HealthSource/Hudson Health Plan (HS/HHP) that is confidential or privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately, either by contacting the sender at the electronic mail address noted above or calling HS/HHP at (914) 631-1611. If you are not the intended recipient, please do not forward this email to anyone, and delete and destroy all copies of this message. Thank You". *********************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://databaseadvisors.com/pipermail/accessd/attachments/20030205/5db6b32a/attachment-0001.html>