I learned something new yesterday about the A2010 Navigation Form and
thought I'd pass it on. With forms/subforms in prior versions you
might do something like this to reference an control.
Me.LastName = Forms!MainFormName!SubFormName!Lname

When I created a NavigationForm I wanted to reference the value in one
subform to filter another subform. Similar syntax like the above does
not work.

I created 2 forms; CustomerDatasheet and CustomerDetail and dropped
them into a Naviagtion Form. I wanted to display the CustomerDetail
record of the record in CustomerDatasheet. I placed a msgbox "In
Datasheet" in the OnLoad even in Datasheet, "In Detail" for the
details form.

When I clicked the respective tabs in the NavigationForm I always got
the OnLoad event message. IOW, when a tab is pressed the form for
that tab is opened, the others are closed. Thus you can't reference a
control between subforms in a NavigationForm.

What I did to create a filter was run a macro in the OnCurrent event
of the datasheet to set a Tempvar to the current ID. Then in the
Navigation Where Clause I entered ID = Tempvars!ID. That filtered the
details form correctly.

There may be a better way to perform a filter action like this. But
this method works fine. If you haven't moved to A2010 yet but are
planning to this tip may help you out

"Patrick Finucane" <patrickfinucanetx (AT) gmail (DOT) com> wrote

I don't know if this has anything to do with the problem you were having;
but your syntax for the control reference is wrong. It should be:

Me.LastName = Forms!MainFormName!SubFormName.Form!Lname

You have to actually reference the form within the subform control (.Form
property), not the subform control itself.

Moving on... I haven't worked with navigation forms, so that may be so, that
it closes and opens forms when you move between tabs. So why not just use a
regular form with a tab control? That would keep the forms open for you.

Neil

On Nov 30, 12:20*am, "Neil" <neil.ginsberg+newsgr... (AT) gmail (DOT) com> wrote:
The Navigation Form is a new beast in A2010. So although your code
would work in older versions it would not work as a Subform in a
Navigation Form.

While searching for a solution I saw many responses/solutions on the
net similar to yours. It is a new feature to Access 2010 and its
concept not understood by those not using A2010. The Navigation Form
is a nice feature but the documentation is extremely limited from MS,
books on Access, and net sources unless one desires really simplistic
examples. Personally, I feel the lack of documentation is due to the
poeple at MS that design Access don't fully understand it themselves
thus they can't adequately describe it to the tech writers. The proof
of this? The lack of examples.

"Patrick Finucane" wrote in message
news:29204c42-17a2-4575-9fe4-1d234533857b (AT) g21g2000yqc (DOT) googlegroups.com...

Sure there is few examples.
However then again this is a new feature.
This will take time for the general community to adopt use and get up to
speed with the new syntax of browse to.

I mean we have 18+ years of previous Access examples built up on the
internet – these things take time and comparing existing amounts of examples
to new features is really not fair at all.

On the other hand a lot of the community doesn't have to use the new system,
and is able to change the source object with standard VBA code anyway.

But lets try a few examples:

I mean, assuming a form called "Main" and we want to swap out a sub-form, we
can use with classic VBA:

Me.custChild.SourceObject = "formB"

Now of course you could use the new browseto and do the same thing with:

DoCmd.BrowseTo acBrowseToForm, "formB", "Main.custChild"

I not sure the people reading this care all that much about the second
example or not.

And heck I suppose we could code this without hard coding the form name
like:

DoCmd.BrowseTo acBrowseToForm, "formB", Me.Name & ".custchild"

So all 3 examples do the same thing;

We JUST changed the sourceobject of a sub from control on the form called
"custChild".

I think at this point, most will drift off and say "nothing to see here"
(and I quite much agree).

For those still reading and not sleeping (I hope!), then of course things
get a little more messy if you take your existing form and drop it inside of
an existing form.

However the real point here is we simply changing the source object of a sub
form control and that this is not a new concept to Access developers.

I mean if you are JUST looking to swap out a sub-form form and filter it
with some drill down and you are NOT needing or wanting the navigation
buttons to change automatic for you?
Then I see little need (or advantage) to use browseto. (it makes no sense).

The navigation system is really a replacement for your main menu or the
switchboard that so many of us lamented over the years.

So if you not needing to have navigation button choices "switch to" when
using "browseto" on a navigation form, then setting source object property
is a better choice in most cases.

If you need filtering, then use the link/master/child settings or even set
filter on the sub form object.
I even often set the sub-form recordSource
(so these are all common and long time approaches that we all used over the
years and should continue to use).

As noted, the only exception or case is when you do not have a CHOICE to
swap out sub-forms and you MUST use browseto (such a case is web based).

There are a few examples here:

http://blogs.office.com/b/microsoft-...ro-action.aspx

Also, if you want some more examples then just download some of the web
templates. They are a great source of examples. They quite much ALL have
browseto commands since for web based applications the SourceObject setting
cannot be used like in VBA applications.

However the syntax transfers over quite well to VBA. So if you are just
looking for some examples, you can use the web based ones.

So the use cases are:

You need/want the navigation buttons to "switch" to a new choice for you
when you use browseto.
The "nav buttons" with the name of the form specified becomes active when
you use browseto IF THERE is a nav button with the name of the form you
specified. (if not, then no navigation button highlight does not occur).

Web based:
You rather must use browseto since you as a general rule DO NOT want a new
browser window to open.

As a result, then in web you need browseto for not only filtering, but it
also enables use of the back button in your browser to return to previous
screen where as using openform in web based this does NOT occur.

For VBA based systems I most certainly suggest you use the new navigation
system to layout and stich together your application forms and dump the old
switch board.

However, for that of filtering a sub form in an existing form? Or even
swapping out a sub-form in a an classic VBA application?

Gee, I would continue to do this quite much the way the Access community has
done such UI setups for many moons.

Anyway, the above links gives some syntax examples, so do the templates - I
note most are web based, but that quite much he motivation for this.

Just remember that each form + sub form is like this:

FormName.SubForm

If you have another level, then you need another pair like:

FormName.SubForm>AnotherFormName.AnotherSubForm

So think of one form you specify as a pair.

I should also note one more great tip is that if you use browseto without a
subform, then your current form is closed and replaced - this is VERY useful
in web based, and I not come up with a use in VBA client based, but I do
often see some asking for the ability to close the current form and open a
new one - browseto can do this trick for you.

eg:

DoCmd.BrowseTo acBrowseToForm, "NewFormToOpen"

In the above we are NOT specifying a "MainForm.subform" pair.

For applications that use tabbed interface as opposed to overlapping
windows?
Well, you never know, but we could see a future in Access where browseto is
used as often as openform!

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal (AT) msn (DOT) com

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote

I used a Tab Control with Subforms to experiment with a similar form of
navigation using either Access 95 or 97 (whenever the Tab Control was
introduced). I did the work for someone, agreeing to charge no more than
"normal" costs, so they didn't have to pay for my learning curve. It turned
out to be usable, but the users reported it was neither any easier nor any
more difficult to use than a normal form-to-form navigation structure, so I
did not pursue it to see if I could improve implementation time to match the
normal development methods we'd used for years.

As I recall, you have 'for ages' been able to use either a SubReport or a
SubForm control on a Report, so maybe (after all these years) adding Reports
to a SubForm on a Form is just "leveling the playing field". My view is that
Reports are for printing, and Forms are for display, so I wasn't exuberant
about interactive Report capabilities when introduced.

Larry Linson
Microsoft Office Access MVP

"Access Developer" wrote in message news:9jnq2bF2psU1 (AT) mid (DOT) individual.net...

To be honest, yes I did have that information floating around in my "brain",
but I did have to "recall it" and I not thought about that feature in some
time.

I have rare used this ability (to my own fault and shortcoming).

A marvelous point, one I had not really thought of....

100% Agreed.

However, we do seem to be "finally" printing less and less paper.

I know! We said computers would allow us to use less paper for years!
In fact the PC desktop revolution cased a HUGE boom in pulp and paper
industry!

However, I am seeing this change in reduced paper use for "real".
With low cost laptops, netbooks, tablet and smartphones etc and
wider use of email, then I am seeing less paper printing occurring
for the first time in 20 years of this industry.

Paper is not dead, but I think we finally turned a point in which we can
and will use less paper on a daily basis.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote

Oh, my, I remember a "kickoff meeting" back in 1984 (maybe 1983) when I was
a wage-slave for "a major computer manufacturer" where our guest speaker was
from IBM's (mainframe) Office and the buzzword was "paperless office". As
he lauded how soon that would happen, I thought "Don't sell you paper
company stock _just yet_!"

Larry

On Nov 30, 3:22*pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal... (AT) msn (DOT) com>
wrote:
Thank you for you input. I created a form that contained a subform
and was able to reference fields between the two in a NavForm.

It works. The NavForm has a NavigationTargetName (the form's name)
and Name property...like NavigationButton2. All of the embedded forms
has the default name NavigationSubform, the tab index always 1 and
that throws me off. And from there there's NavigationControl0.

It'd be nice, IMO, if we could had a built-infunction called
FormReportPath("Optional Property") we could call, and it would
debug.print the path of the control in a form when running and print
output for Forms!ManForm!FormSubForm.Form... I'll assume that'd save
developers some time.