ccocker:
Hang tight!
I had one (many explictives) learning to use this control.
Things to keep in mind:
- The new navigation pane works much like a late bound tab control. It is NOT however at all like a tab control
- Each time you click on a new navigationcontrol button/tab, the associated subform is RELOADED from SCRATCH. The subform on the control that you were on is UNLOADED; thus, anything that you had set on that form is NO LONGER available! You have to use the onclose events, temp and module level variables, and other tricks to preserve and transfer the infromation.
- There is ONE navigation control container on the parent form. This is where all of the subforms refered to by the navigation button/tabs will load. Therefor, ignore the button name and go from the parent to the navigation control then the subform therein.
This will sometimes get you the correct reference and helpeed me a few times:
How to refer to subforms in control sources There's a trick to this with the navigaton control - while in design view make sure that the correct subform is showing... and this doesn't always work.
Your basic reference is something like this and assumes that you haven't changed the default navigation container name:
[Forms]![frmParentform]![frmNavigationsubform].[form].(somecontrolhere)
I'll update here with a better example in a few hours after I get a nap and goto work :)
()Also, almost as an aside this is a very handy link to have when working with subforms and was actually of some use while trying to learn the new nav control:
Refer to Form and Subform properties and controls
I'm glad this worked out.
By way of finishing the reference as promised in my first post :)
So I have a calculated control that requires the value from the subform of the parent form within the navigation control.
Unless you have subforms within subforms this is more than likely as bad as it gets.
So We have three forms involved here:
frm_navigation: This is the switchboard. It has all the pretty buttons along the top and side for user navigation.
frm_qry_asset_inventory_logbook: This is the parent form that is bound to the navigation control button. It's a fairly complex query driving this form; however, as one scrolls or searches within this form for an asset, the subform pulls the historical information.
sfm_qry_asset_inventory_logbook this is the subform frm_qry_asset_inventory_logbook that pulls the related records from the history/logbook table for the selected asset in the parent.
We then have the bound control on the subform that I'm after:
[history_fk_inventory] which is bound to that recordsource field in the sfm_qry_asset_inventory_logbook form. I need to pull this value into a control on the parent for a calculation.
So this is what it looks like in the calculated control (ok only partially this has a very long set of calcs)
- =[Forms]![frm_navigation]![NavigationSubform].[Form]![sfm_qry_asset_inventory_logbook]![history_fk_inventory]
so to break this down by step:
-
[Forms]! '<Forms Collection
-
of the database
-
-
[frm_navigation]! '<The Switchboard form
-
-
[NavigationSubform]. '<The default name of the
-
new Acc2010 navigation control
-
-
[Form]! '<Tells us to look at
-
the form property of the
-
navigation control,
-
in this case it
-
is the parent form:
-
frm_qry_asset_inventory_logbook
-
-
[sfm_qry_asset_inventory_logbook]! '< This is the subform of the
-
Currently loaded parent form
-
-
[history_fk_inventory] '< and finally the
-
control of interest. <
So that got me to the control on the subform of the parentform loaded into the navigationcontrol.
What if we needed to get a control on the currently loaded form in the navigation control (we're still using the three afor mentioned forms here):
- [Forms]![frm_navigation]![NavigationSubform].[Form]![Inventory_pk]
Note I did not use "frm_qry_asset_inventory_logbook"
In fact, if you clicked on a second button, and it loaded a new form (say frm_example2) with the bound control named "[example_pk]" then the reference to that control would be
- [Forms]![frm_navigation]![NavigationSubform].[Form]![example_pk]
Clear as mud... was for me too.
Fourtunately however, when working within the loaded form; the
"ME." construct holds true as does any of the references internally to the form using "Me." and the normal subform references (for example say:
in vba:
sfm_qry_asset_inventory_logbook
wanted to address the recordset for:
frm_qry_asset_inventory_logbook
(both of which are currently loaded into "NavigationSubform"
then the in vba code within "sfm_qry_asset_inventory_logbook" need only use the construct:
Me.Parent.RecordSource
and other constructs as shown in the link provided earlier.
-
Moveing data: there is, in the navigation control, the tab (button) that is associated with the form, a property, "Navigation Where Clause"
I've just started playing with this... taking the inventory forms... I have a tab that loads the inventory form... I already have a tab that has the history details... so I've been working with this property so one could select the item in the inventory pane and go directly to that item in the history side.