[AccessD] Advanced Unbound Form With Classes and Collections Part 1

So far we have created a workable unbound form, with the basic elements of
viewing/editing data in a table.  We have done so with Class objects and
Collections.

 

Let's go a step further.  What we have done up until this point is mimic
functionality that is just as easily accomplished with a bound form, and
with less work.  From this point on, I will be explaining concepts and
showing methods that take unbound forms to the next level.  This is where
unbound forms get an edge over bound forms.  Before we continue, keep in
mind that unbound forms are not for everything.  Microsoft Access is a RAD
tool, and bound forms are a part of that rapid development functionality.
VBA is a tool within that environment, and it is a very powerful tool
indeed, in fact, it's possibilities are practically endless.  So please put
this tutorial into the 'Some Projects' category, understanding that the
methods/concepts to follow won't apply to all projects you develop, but for
those that it does apply, you will see major advantages.

 

 

The concept of object oriented programming can be a little daunting to some
developers.  Microsoft has an example in the MSDN dealing with this about
dinosaurs.  It gives an example of creating a dinosaur class, and goes on to
explain how to create different types of dinosaurs using a 'basic' dinosaur
class.  In VB/VBA, this is done with Implements.  Implements is a limited
form of inheritance.  Ah, the big 'inheritance' word.  Well, in VB.Net,
there is inheritance, but not in VBA.  Confused?  If you are, join the club.
Let's see if we can't make things a little bit clearer.

 

To begin with, let's look at our example, and see how it is object oriented.
As Access Developers, it's all about the data.  The core of most of our
projects is table structure and the data within those tables.  Non-data
centric projects are a whole different topic, and really should be developed
in other environments.  Are tables objects?  Yes, to Access they are, but
they are non-descript objects to any particular project, labels for things
that should be more specific.  In our demo project, we created a table to
hold information about people, tblPeople.  Now, tblPeople is a more specific
object, it's an object that stores our data, however, it is still just a
table 'object'.  It's properties and methods are representative of a TABLE,
not of the data the table represents.  Does that make sense?  In code, we
can do all sorts of things with a table object, or even a recordset object,
however, what we can do is based on a GENERIC table or recordset.  An
'Object' in code is a representation of something, either physically or
conceptually.  Obviously a table is not a 'physical' object, other then the
electrons used to read/write the bits/bytes.  But let's pretend that it is a
physical object.  We can see it, just can't touch it.  So things like a
form, table, recordset, database, those are all objects which are physically
represented in code.  A conceptual object would be more along the lines of a
ADO Connection object.  It represented a 'link' to a database.  It too has
properties and methods too, however it is a 'concept' within ADO, not an
object we can 'see'.  Think of it like a cell phone.  The cell phone would
be the physical object, like a database, and the connection to the cell
tower would be the 'conceptual' object, like the ADO Connection object.

 

If you have written VBA code while developing, you have more then likely
already been using Objects.  Tabledefs, QueryDefs, recordsets, Forms,
Reports, these are all class objects in code, they are just prebuilt.  The
purpose of this tutorial is to help you develop your code in the same
manner.  In the beginning and intermediate tutorials, we created some class
objects in code.  Just like a recordset object represents the data within a
table or tables, we built a People class, which represents a person.  To
represent everyone, we built a People class.  tblPeople may store the data,
but the People class 'represents' the data.  

 

Set rs=CurrentDB.OpenRecordset("tblPeople", dbOpenTable)

Rs.movefirst

Debug.print rs.fields(0).value

 

The code above applies to a recordset object, in fact, any recordset.  Even
though we are pulling up data from tblPeople, it doesn't really represent
the specifics of a person.  Our Person class on the other hand does:

 

Dim ps as Person

Set ps=new Person

Ps.ID=1

Debug.print ps.FirstName

 

The code above represents a person, not a table, or recordset, it has
properties and procedures specific to a person in our in database.

 

In the next part, well get a little more into collections.

 

Drew