[AccessD] Assistance

ROTFLMAO.

Some things are just worth doing, always. 

Because of my dictatorial methods I am able to just look at my tables and
see the relationships, know what tables a field is in etc.  Works for me.
Most of my subjects don't dare speak up anymore, knowing my "out the door,
without a parachute" mentality.

;-)

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 11:15 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Assistance

Well, thanks to you and your dictatorial methodology I find I am now
completely unable to create a new table without defining an autonumber PK as
the very first field.  With ID as the suffix of the field name.

Thanks a lot.

And I mean that.

Rocky


John Colby wrote:
> 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