[AccessD] Two levels up (or down) , twice removed

Jim Dettman jimdettman at verizon.net
Wed Feb 3 14:37:28 CST 2010


<<I use an unbound parent "wrapper form" with all of the other forms as
first level children. The 
form also has a series of hidden text boxes which point to the PK in the
parent form. I use the  
textbox as the "Link Master Field" for the child form.>>

  That's the same thing I do (use a hidden control); got it out of the ADH
2.0 handbook.  Most miss the fact that a master link can be a control or a
field.

  So I put a hidden control on the main form, child form linking is normal,
then place the grandchild form on the main form and use the hidden control
as the master link.  Last piece is in the child forms OnCurrent event, I
update the hidden control on the parent. 

 With this, you can easily do a Main Form (Customers), Child Subform
(Orders), and Grandchild Subform (Line order detail).

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
Sent: Wednesday, February 03, 2010 2:36 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Two levels up (or down) , twice removed

If you think about it, the parent can't finish loading until it's children
have loaded since they 
are in controls inside the parent.

I use an unbound parent "wrapper form" with all of the other forms as first
level children. The 
form also has a series of hidden text boxes which point to the PK in the
parent form. I use the  
textbox as the "Link Master Field" for the child form.

Most of the system I do these days use this method extensively.

As an example, tak a geographic system using a hierarchy of:
Province, District, LLG (Local Level Government Area), Ward with

tblProv = Prov_PK,Prov_Name....
tblDist = Dist_PK, Prov_FK, Dist_Name.......
tblLLG = LLG_PK, Dist_FK, LLG_Name...
tblWard = Ward_PK,LLG_FK,Ward_Name......

I create an unbound form frmMain with 4 child forms
frmProv, frmDist, frmLLG, frmWard.
I place the 4 child forms side by side on the parent form

I  create 3 hidden text boxes
txtProvLink  = [frmProv].[Form]![Prov_PK]
txtDistLink  = [frmDist].[Form]![Dist_PK]
txtLLGLink  = [frmLLG].[Form]![LLG_PK]

I  set up the child form dependencies as:
frmDist: Linked Master Field = txtProvLink, Linked Child Field = Prov_FK
frmLLG: Linked Master Field = txtDistLink, Linked Child Field = Dist_FK
frmWard: Linked Master Field = txtLLGLink, Linked Child Field = LLG_FK

This method completely solves your problem. A child form does not update
until the form 
above it has finished updating.

It also has a few other advantages:
allows you to have as many generations as you can fit on your screen
you can use any combination of  Single Form and Continuous Form  at the
various levels.
you can layout the screen in any way you want, you don't need child forms
completely 
embedded inside its parent.


-- 
Stuart


On 2 Feb 2010 at 23:54, jwcolby wrote:

> As you probably know by now, subforms load before parent forms, and their
current events fire before 
> the parent's current event.  It always puzzled me how they pull off this
trick, but they do.
> 
> Usually this is not a problem but it can be.  For example, the main form
has a "client" combo / 
> field.  The child form does not use or care about that.  The grandchild
form however needs that 
> value to filter a combo to only display records from a table for that
specific client.
> 
> In this case, it doesn't appear to work correctly.  The combo in the
grandchild form is always a 
> step behind the parent form, IOW if the parent displays client A, the
combo in the grandchild 
> displays whatever the parent had the PREVIOUS record.
> 
> So the current event of the main form fires last after all of the child /
grandchild forms load (and 
> their load / current events fire).  Logically, that current event of the
main form needs to reach 
> two levels down and tell that combo to requery itself.
> 
> What a PITA.
> 
> I actually built in to my framework collections of dependent child objects
so that I could tell a 
> form or a control on a form that "these objects are dependent on your
data" and call those objects 
> and requery them.  Of course I have to write code in the load event of the
form to set up the 
> dependent object hierarchy.
> 
> So how do YOU handle this kind of situation?
> 
> Curious minds want to know.
> 
> -- 
> John W. Colby
> www.ColbyConsulting.com
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.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