Stuart McLachlan
stuart at lexacorp.com.pg
Wed Feb 3 01:36:28 CST 2010
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