[AccessD] Framework book - was caption from code

Jim Dettman jimdettman at earthlink.net
Wed Jul 13 06:55:07 CDT 2005


John,

<<Indeed it would be even more critical to use a framework as you the
developer are doing so much of the work that Access was doing for you -
loading all of the data into the controls, checking for updates to the data
by other people before you wrote changes back to the table, writing the data
back from controls into fields in the tables, stuff like that.  All of that
code would be framework material.  Once written and stored in the framework,
the doing of it would be automatic by the framework.>>

  There was a discussion long ago on this very point; why there were not
more frameworks available for Access.  The consensus at the time was that
Access did a lot of what a traditional framework did for you.

  For example, I work with VMP which is a framework for VFP and one of the
base services it offers is PK generation.  Foxpro for the longest time
didn't have an Autonumber, while Access has had this from day one.

  The other problem was that Access did not provide many hooks, so it was
difficult to achieve certain things.  A lot has changed since then and yet
there is still a fundamental lack of frameworks for Access.

  It's strange to because in working with many applications, I see that
other developers have come up with things to solve the very same problems
(PK generation, pick lists, calendars, etc).

  I'm still scratching my head as to why.

Jim.



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby
Sent: Wednesday, July 13, 2005 7:35 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Framework book - was caption from code


Jim,

My framework (the part that had to do with forms and controls) was indeed
aimed at bound forms.  However the concept works for unbound forms as well.
Indeed it would be even more critical to use a framework as you the
developer are doing so much of the work that Access was doing for you -
loading all of the data into the controls, checking for updates to the data
by other people before you wrote changes back to the table, writing the data
back from controls into fields in the tables, stuff like that.  All of that
code would be framework material.  Once written and stored in the framework,
the doing of it would be automatic by the framework.

If you are one of the unholy (unbounders) why don't you give a thumbnail
sketch of how you manage all of that work.  I will then brainstorm how I
would look at doing it in a framework.  Remember that the concept of a
framework is to make it as automatic as possible.  For example (in a bound
form) I have a form class and I have a class for each control type.  The
form class runs a control scanner, gets the control type of each control,
loads a class instance for each control found.  Once this is done, the form
class and control classes can work together to do tasks.

As an example, I can literally just drop a pair of controls on the form, a
text box named RecID that exposes (is bound to) the PK (always an
autonumber) and an unbound combo called RecSel.  The names are specific and
if the control scanner finds this pair of controls it knows that a record
selector exists and runs the code.  The afterupdate of the combo by that
name calls a method of the parent form saying "move to recid XXXX".  The
column 0 of the combo is the PK of the record in the form so it knows the
PK.  The form's OnCurrent knows that it needs to keep the combo synced to
the displayed record in the form so it calls a method of the combo class
telling it to display the data relevant to the current record in the form.
Thus the form, the combo and a text box all work as a system to form a
record selector.  If the developer drops these two controls on the form he
"just has" a record selector.  Nothing else is required - other than binding
RecSel to the PK field and setting the combo's query to display the data and
get the PK of the records in the table.

As an unbounder, you need to think about how to achieve this kind of
"automaticness" in the things you do.  Naturally some tasks do require
feeding data into init() methods of classes to set the classes up to do
their job.  After that though the "systems" need to just work together.
Load the data into the unbound form / controls.  Store flags in each
control's class saying that control's data was modified.  Scan for all
controls with modified data and update the underlying data in the record.
Check for data changes in the data you are about to update and inform the
user that another user edited the record since you loaded the data.  Etc.

John W. Colby
www.ColbyConsulting.com

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: Wednesday, July 13, 2005 2:29 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Framework book - was caption from code


Hi John:

Save a copy for me. It sounds like a good read...but I guess it only works
with bound forms.(?)

Jim



--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com





More information about the AccessD mailing list