[AccessD] Classes: organizing your code

Yes, good idea to use a function like that.  I must admit, since I
rarely create production Access interfaces, I don't bother with that,
because that is an Access quirk, you can be running Access (or any
office VBA environment) and STOP the running code, but still have the
database open.  With VB or ASP, that's not the case, stop the code, and
the application closes....

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, February 25, 2009 3:50 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Classes: organizing your code

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.
> 
> 
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
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.