[AccessD] Basic Unbound Form with Classes and Collections Summation.

I don't want to start a naming convention debate here, but I would like to
explain my method used in this example.  First of all, I do not prefix my
class object names.  Instead of objPerson, I just put person.  The reason I
do this is because other 'existing' objects don't have prefixes, such as
Recordset.  It's Recordset, not objRecordset.  I have found that the more I
use class modules, the more I begin to program on an Object Oriented basis,
and leaving the prefixes out helps with that mentality.

Within the objects I don't prefix properties.  That is along the same line
of thinking.  You don't see Recordset.intCount or Recordset.lngCount, you
see Recordset.Count.  The properties of an object are usually obvious as to
their nature.  If I create a Get/Let property, I do set it's module level
variable with a prefix.  For example, for FirstName, if I would have created
Get and Let statements, it would have looked like this:

Dim strFirstName As String

Property Get FirstName() as String
FirstName=strFirstName
End Property

Property Let FirstName(strEnter as String)
strFirstName=strEnter
End Property

That is another reason why I do not prefix properties, because it is easier
to tell in code what is a property and what is a 'value holder' variable by
whether or not it has a prefix.  

Next, error handling, I put none in the example.  Sorry, this is a tutorial,
if you want lessons in errorhandling, that would be a whole different
discourse.  Personally, when I develop a project, errorhandling is
determined by the project itself.  Simple projects I don't bother at all, if
they aren't something that is going into production.  When developing in VB,
if it's a .dll (that I'll use for the web) or an .exe I am setting up for an
NT service, then I put in errorhandling from the get go.  I also do that if
it's a large project where I have things mapped out from the get go.  If
it's a smaller project or just a plain .exe/.mdb, I tend to skip
errorhandling until the project is tested.  I prefer to put the
errorhandling in place afterwards, so that it's easier to debug (because
errorhandling is a little bit of a pain to debug on the fly).

Next, classes themselves.  It takes a different mindset then programming
just basic modules.  It's far more organized however.  For example, in this
demo, we are organizing each record in it's own class 'Person', and those
are then grouped together in the 'larger' class People.  Coding this is far
more organized and even easier.  In straight VB/VBA, if we were tracking the
same data, we would be using arrays, and that just gets confusing.
PeopleArray(1,2)...what does that mean?  However, if we use a Person
variable, such as ps, when we code, we type ps. and we get a list of
properties in a drop down (isn't intellisense handy?), and the resulting
code is ps.FirstName, that makes a lot more sense then points in an array.  

Plus, classes let us derive values automatically.  In our example, we
created a FullName property.  One line of code that is run no matter what
instance we are using.  The data is already present.  Now, we only created a
Property Get statement, which means if we said ps.FullName="Joe Bob" from
code, the code would give us an error stating that the property is read
only.  In the intermediate example we will create a Let statement for that.

For the sake of thread easiness, please post questions to this particular
less with a subject of 'Basid Unbound Form: (your question)'.  That way we
can let people decide what stuff they want more information on.

Okay, now I'll start the intermediate demo.  Don't through out our sample,
we are just going to build upon it.

Drew