[AccessD] Assistance

John Colby jwcolby at ColbyConsulting.com
Tue Feb 28 21:46:29 CST 2006


LOL, 99% of my forms are bound.  99% of my forms do some pretty "fancy"
stuff via my framework as well.  

For example, I have a "REC_ID" text box on every form which is bound to the
PK of the table the form collects data for.  The REC_ID on the opening form
is bound to the PK so it has information on the field name for the PK which
I can use in building "move to" code. If a combo on another (child) form is
displaying a record, the combo has the PK VALUE of a specific record in the
parent table.  If a user dbl clicks a combo box, my framework can cause a
data entry form to open displaying data from the parent table that the combo
is displaying.  Since I know the PK from the combo that was double clicked,
and I know the table and field of that PK from the REC_ID control, I can
instruct the form to "find" that PK.   I therefore have all the pieces
needed to open the form and move to the record that the combo was
displaying.  If the combo back on the calling form was on the new record, it
will NOT be displaying data.  That is a signal to the opening form to move
to a new record so that the user can enter data.  I use the same basic logic
for the "not-in-list" event of the combo to allow the user to automatically
open the data entry form for a combo, move to the new record, and enter new
data in the table.  When the form closes, the combo requeries and now
contains the newly entered data in the list table.

That kind of stuff.  

My framework provides dozens of "behaviors" that are just there if I want to
use them.  In the OnOpen of a form, when I set up the form class, I can
specify that "this combo is dependent on that combo".  When the class for
this combo is requeried, it automatically requeries all "dependent" object
classes.  I can have subforms, combos, list boxes etc. all "dependent on" a
given object.  As long as each of these dependent objects has a "requery"
method, I can just iterate the colDependentObject collection of the class,
requerying all dependent objects.  The current event of a subform can cause
the form class to requery all "dependent objects" dependent on that current
record of the subform.  Of course all dependent objects have to have
feedback in the query that allows it to display different data depending on
the current row of a form, or the selected item in a combo etc.  But if you
set it all up, and "inform" the framework (objects) that other objects are
dependent on them, then they all get requeried when the master object is
requeried.  A combo can have a dependent combo, which can itself have a
dependent combo.  Change the first combo, it requeries the second combo.
The second combo then requeries the third combo etc.  The third combo could
requery 5 subforms.  Your imagination is the limit.

This kind of stuff can make the creation of dependent combos and subforms a
snap.

Just one of dozens of behaviors built in to the framework.

Yea, I use bound forms, I use autonumber PKs, I use a framework, and I make
good use of all of the above.

John W. Colby
www.ColbyConsulting.com 


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin -
Beach Access Software
Sent: Tuesday, February 28, 2006 9:15 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Assistance

Bound or unbound forms?

Rocky


John Colby wrote:
> Folks,
>
> I am looking for a "junior level" person to assist me in getting some 
> of my back log caught up.  I need one person, able to:
>
> Read and program VBA, guru not required.
> Understands and can build Access tables, queries, forms and reports.
> Must understand data normalization and be able to correctly sort out 
> what data goes where given a set of objects / attributes.
> Must be able to read, understand and build relationship diagrams in 
> the relationship window in Access (the center of my universe).
> Has a few hours a day available (10-20 hours a week).
> Must be self starter, blah, blah, blah.
>
> If anyone out there thinks they might fit the bill, please respond 
> OFFLINE - email a resume, and introduction email with required hourly 
> wage to jwcolby at colbyconsulting.com.  The more you know and are 
> capable of the more work I have.
>
> Thanks,
>
> John W. Colby
> www.ColbyConsulting.com
>
>
>   

--
Rocky Smolin
Beach Access Software
858-259-4334
www.e-z-mrp.com

--
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