[AccessD] Intermediate Unbound Form Summation.

DWUTKA at marlow.com DWUTKA at marlow.com
Mon Jun 12 14:53:45 CDT 2006


Let's review what we have done so far in our unbound demo database.  I know
I posted a lot of code in some places with little explanation.  There was a
reason to this madness.  We built a framework of sorts, and some pieces just
had to be there so that it could support the rest, so we were coding things
that didn't make sense on their own, but were used in later pieces.

You may have noticed that we jumped around a bit when building our project.
We were going back and forth between both classes and the form.  This was
due to creating the project in two phase.  A basic phase, and an
intermediate phase.  If you would have started this project at just the
intermediate phase, you would have created the Person class in it's
entirety, then the People class, then the form (which is also a class (the
code behind forms and reports are class modules)).

When developing with Class modules, you want to plan out how you want your
objects to interact.  Your first few projects may end up similar to how this
lesson has gone so far, going back and forth between your objects as you
discover the need for more funcationality. But as you get used to building
classes, you will find a pattern of functionality that you can stick too.  

For instance, with our Person class, we would determine what functionality
we want before we build the class.  In this case, we want the ability for it
to be stand alone (which we did not use, but it could be used in other
portions of a real project).  Let's look at the functionality that we
actually needed.  We wanted to display and modify the people in tblPeople.
To do this, we created properties representing the fields (FirstName,
LastName).  These fields, in our example, didn't need any extra logic.
However, in a full bore project, they just might have.  We might want logic
to set the text to Proper Case in a let statement. 

We did create a property which had no direct tie to the data (fullname).  It
was derived data, but in the intermediate phase, we created a Let statement
to allow that property to populate the other properties.  This was used when
we created the AfterUpdate events for our text fields.  When you changed any
of the fields, it affected the others. (ie, change the first name, and the
full name was changed, change the full name, and at least one of the others
was changed, if not both.).

Once the Person class would have been fully developed (to encapsulate the
requirements of the project), then we would have moved to the People Class.
Again, through the two phases of this demo, we have modified the People
Class to accomodate new capabilities.  These would have all been put in
place before we moved on to the frmPeople form.  

So what kind of considerations do we need to think about when designing a
project?  There are the obvious ones, such as data integrity checks, data
manipulation, recordset interactions (pulling up the data, editing the data,
adding data, deleting data).  Some of the less obvious ones are user
interactions.  In our example, we created 2 different sort orders, and the
method in which the data was displayed/sorted required properties with the
Person class, and properties in the People class.  In the Person class we
created First and Last sort order numbers.  In the People class, we created
properties to retrieve the proper Person based on either the first sort
order, last sort order or the person's ID (which was a field we had in place
already, to represent data in the tables).  Planning projects like this can
take some time, but like I said, it only takes a handful of projects before
it becomes second nature.  Some things we put in place may not make
immediate sense, for example, in the Save function of the Person Class, we
set the ID property when it's a new person.  That has an actual purpose
relating to operability.  When a user was changed or added, the sort order
had to be rebuilt, and without the ID, we wouldn't be able to 'stay' on the
same current person.

Again, if you have any questions about what was done in the intermediate
example, please preface your posts with 'Intermediate Unbound Form: (your
question topic)'

Drew



More information about the AccessD mailing list