[AccessD] Classes: organizing your code

jwcolby jwcolby at colbyconsulting.com
Wed Feb 25 15:49:57 CST 2009


Drew,

I just discovered by experimentation that you can reference moduleName.PublicVariable.  You can also 
declare property get/let/set statements and reference the properties.  Likewise public functions / 
subs show up.  This makes the module (at least in syntax) somewhat similar to the .Net class where 
you can use it without instantiation.  Of course no sinking events.

Kind of cool, though I will have to think carefully about whether I would replace my classes where I 
only have a single instance of the class - for example my base framework class.

One of the thing that I use a LOT in my classes is the initialize and terminate events to 
automatically set up and cleanup things like collections, child classes and so forth.  That 
capability would not be there using this module reference syntax.

BTW, I have taken to doing the following:

private OS as OperatingSystem
function cOS() as OperatingSystem
	if OS is nothing then
		Set OS=New OperatingSystem
	end if
	set cOS = OS
end function

Then my syntax is

	if cOS.NTBased() then
		'Do something
	end if

I started doing that because it allowed me to reinitialize a variable trashed when I STOPPED my 
code.  Just calling cOS automatically reinitializes if OS has been set to nothing.

John W. Colby
www.ColbyConsulting.com


Drew Wutka wrote:
> Just wanted to post an example of how classes can organize your code.
> 
> Everyone that codes in VB/VBA already uses classes.  Forms and Reports
> are class modules.  When you use a recordset, that's a class.  Any
> defined object (control, form, recordset, etc.) is a class object.  The
> ability to create a class object allows a developer to organize their
> code in the same way.
> 
> Let's take a recordset object, for example.  If the recordset wasn't an
> object, but just a vast list of functions/subs that returned values,
> imagine how complex your code would be.
> 
> Instead of:
> 
> Dim rs as ADODB.Recordset
> Set rs=new ADODB.Recordset
> Rs.open
> "tblSomeTable",currentproject.connection,adopenkeyset,adlockreadonly,adc
> mdtabledirect
> If rs.eof=false then rs.movefirst
> Do until rs.eof=true
> 	'do something
> Loop
> Rs.close
> Set rs=nothing
> 
> We'd end up with something like:
> 
> Dim TableArray()
> Dim  RecordArray()
> Dim blRecords as Boolean
> Dim intFieldCount as long
> Dim intRowCount as long
> blRecords=fAreThereRecords("tblSomeTable",1,512,0)
> TableArray=fGetRecords("tblSomeTable",1,512,0)
> intRowCount=Ubound(TableArray())+1
> for i=0 to intRowCount-1
> 	RecordArray=fGetRecordFromTable(TableArray(i))
> 	intFieldCount=Ubound(RecordArray())-1
> 
> etc. etc.
> 
> We wouldn't have defined data types for the appropriate records, we'd
> have to remember function names for all sorts of processes that are
> already part of the recordset object.  Ugly....
> 
> So here's an example of custom classes:
> http://www.marlow.com/Classes.zip
> 
> That zip contains a database with two class objects, GeneralSystemInfo
> and OperatingSystem.
> 
> It has a form that uses both (frmGeneralSystemInfo).
> 
> Instead of having to remember various function names to get certain
> pieces of information, I have built these classes to make my coding
> simpler.  
> 
> For example, let's say I want to know if the system I am dealing with is
> an NT based system:
> 
> Dim OS as OperatingSystem
> Set OS=New OperatingSystem
> If OS.NTBased then
> 
> End if
> Set os=nothing
> 
> No need to remember individual function names, all the stuff I typically
> want to know or do with the Operating System is in that one class
> module.
> 
> Isn't that easier to read and follow?
> 
> Drew
> The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.
> 
> 



More information about the AccessD mailing list