How to reference a sub-subform in a navigation form from outside form

[daryll]

What is the appropriate path to reference a sub-subform in a navigation form from outside form. This path work if you are in the navigation form, but not on outside form.

Forms![Nav Form Attachment]![NavigationSubform].Form.[Pool eFile Attachment].visible=True

 

[Ranman256]

the BUILDER will provide you with the correct path.
(use a query to paste the path in)

yours looks correct.

 

[daryll]

I'm not familiar regarding "the BUILDER or use a query to paste the path". Kindly explain further.

 

[Pat Hartman]

What is the appropriate path to reference a sub-subform in a navigation form from outside form. This path work if you are in the navigation form, but not on outside form.

The Navigation form is a special purpose form and it works differently than you might expect. The nav form uses a SINGLE subform control. As you click navigation buttons, a different form gets loaded into the control. That means that ONLY the currently active subform is ever available. But, you would address it as you would address ANY subform.

Forms!yournavformname!thesubformcontrolname.Form!yoursubofrmfieldname

"thesubformcontrolname" is static. It is ALWAYS the Name property of the subform control REGARDLESS of what form got loaded into the subform.

 

[daryll]

@Pat Hartman

Forms!yournavformname!thesubformcontrolname.Form!y

This example you've given me would not work. As i've tried interchanging "! and ." prior posting here. I was googling with regards to this but all examples are referred inside the navigation form like my code posted above.

 

[Galaxiom]

What is the appropriate path to reference a sub-subform in a navigation form from outside form. This path work if you are in the navigation form, but not on outside form.

Forms![Nav Form Attachment]![NavigationSubform].Form.[Pool eFile Attachment].visible=True

That reference is in the context of the Application and refers via the Forms Collection. If it works inside the form it should work outside the form.

If a multilevel reference throws an error I usually beak it down and try it piece by piece from the Immediate Window using the Name property which all these objects have.

? Forms![Nav Form Attachment].Name
 
? Forms![Nav Form Attachment]![NavigationSubform].Name
 
? Forms![Nav Form Attachment]![NavigationSubform].Form.[Pool eFile Attachment].Name

First one that breaks is where to start looking for the problem.

BTW I strongly recommend you discontinue using spaces in object names.

 

[daryll]

@Galaxiom
That would be a great hint. I'll try your suggestion

 

[daryll]

Now I spotted the problem. Just to share my experience, which is i know some people may find it obtuse. Anyway.

My navigation form has a two tabs and this form is designed to pop-up once the user click on a control (i.e. textbox) which I set the on click event on it. I noticed that when you refer a subform which belongs to the first tab it doesn't throw any error. Which means that the path I posted above is valid. For the sake of clarity this is the path of the subform.

Forms![Nav Form Attachment]![NavigationSubform].Form.[Pool eFile Detail].visible=True

However, when you refer a subform that belong to the second tab using the same pattern i.e

Forms![Nav Form Attachment]![NavigationSubform].Form.[Pool eFile Attachment].visible=True

it throws an error "can't find field |1 referred to your expression" but if you navigate to the second tab without closing the Navigation Form and again clicking on the control (i.e textbox) which is on the main form then that path is valid.

So my question now, how can I make the path on which the form will not throw any error?

 

[Pat Hartman]

it throws an error "can't find field |1 referred to your expression" but if you navigate to the second tab without closing the Navigation Form and again clicking on the control (i.e textbox) which is on the main form then that path is valid.

So my question now, how can I make the path on which the form will not throw any error?

I gave you the answer:

The Navigation form is a special purpose form and it works differently than you might expect. The nav form uses a SINGLE subform control. As you click navigation buttons, a different form gets loaded into the control. That means that ONLY the currently active subform is ever available. But, you would address it as you would address ANY subform.

That means that you CANNOT reference a form that is not loaded. Period!!! If tab1 is active, NOTHING on any other tab can be referenced.

If this is a problem for you then you cannot use a navigation form. You will have to build your own which is what we did for almost 20 years before MS decided to "help" us with a new form type that doesn't work (nor should it) like the forms we used to design ourselves. The navigation form works this way because it is intended to be a menuing system and so manage a large number of other forms. The main form would simply be too "heavy" and therefore clunky and slow if all the forms were always loaded. The decision was made to load only the active form. This works in the vast majority of cases. It is only when one form is related to another that the method fails.

You might be able to solve the problem by making your form a tabbed form. That way, both forms will be loaded into the nav subform control and therefore both can be referenced..

 

[daryll]

I gave you the answer:
That means that you CANNOT reference a form that is not loaded. Period!!! If tab1 is active, NOTHING on any other tab can be referenced.

I didn't get your point clearly nor paying attention to it. May be I was too carried to receive an answer seeing a code directly. And beside, this is my first project with MS Access.

Your warning was right I really didn't expect it behaved that way. Anyhow, now you've explained it directly it really gave me a clear insight. Thanks @Pat Hartman

One more thing, by using docmd.browseto prior to initiating the subform path will it solve the issue?

 

[daryll]

You might be able to solve the problem by making your form a tabbed form. That way, both forms will be loaded into the nav subform control and therefore both can be referenced..

Did you mean a subnavigation form of the current nav form? Or may be not.

 

[Pat Hartman]

No. I meant what I said - a form with a tab control on it. You can have separate subforms on each tab page if that will solve your problem. Since it is NOT a navigation form, you CAN have multiple forms loaded at the same time. Of course without knowing more about WHY you need to reference one form from another, we really can't be much help.

Just remember, a subform on a subform is one level deeper you'll need additional stanzas in your Forms!.... reference to get down to the subform.

 

[daryll]

This trick solve the issue.

In order to not let the form throw an error, first execute the docmd.browseto (browse to second tab) prior to

Forms![Nav Form Attachment]![NavigationSubform].Form.[Pool eFile Attachment].visible=True

.

 

[Pat Hartman]

Glad it worked for you.

 

[RobDuggan]

The Navigation form is a special purpose form and it works differently than you might expect. The nav form uses a SINGLE subform control. As you click navigation buttons, a different form gets loaded into the control. That means that ONLY the currently active subform is ever available. But, you would address it as you would address ANY subform.

Forms!yournavformname!thesubformcontrolname.Form!yoursubofrmfieldname

"thesubformcontrolname" is static. It is ALWAYS the Name property of the subform control REGARDLESS of what form got loaded into the subform.

Hi Pat - im very sorry to reply to an old thread but I am super stuck - actually just signed up to as you a question on this.

Basically I have a Main Navigation form (Top Bar) =. frmNavigation
Then under each man control I have a another Nav form called for example navIR
Then in that tab I have say 5/6 navigation tabs and these refer to direct forms I have build and some have subform and sub form controls in them.

Been really really struggling with completing action and passing details among these.

Here is an example of one I desperately need help on

frmNavigation - frmNavIR - frmSnaphot - (subform here)

When I try to update fields on frmSnapshot after I click on a record on the subform it doesn't recognise that frmSnapshot is open. I have tried doing all levels and single levels. Everything.

Any suggestions?

 

[arnelgp]

maybe a demo db will demonstrate what you mean.

 

[RobDuggan]

maybe a demo db will demonstrate what you mean.

Unfortunately I cannot upload the tool - my work environment is extremely strict so im on the forum on my personal PC

I actually found that what Pat suggested works but not with 2 layers of navigation forms. So I have made the painful decision to rebuild my navigation to use 1 level but both Left vertical and top horizontal. Then it seems to work.

Too many layers/subforms I think - lost sooo many hours ... thanks anyway.

One positive is I finally signed up. Hopefully I can help others

 

[Pat Hartman]

@RobDuggan Welcome aboard
The reason you should not post in old threads is because the answers become confused and NO ONE wants to read through a thread with a large number of posts to try to figure out what is going on. So, if you find a similar answer, rather than posting in the thread, start a new one and post a link to a partial answer and tell us what else you need.

I don't use the navigation form myself because it is too awkward to always be working with a subform and it interferes with my ability to use the open form method and pass in selection criteria and the open args. So, I don't like the way it works. I also don't want to "hard code" my menu. The form looks nice and if you have a small app with fewer than about 20 options, is is useful. But it does not scale well and you cannot nest navigation forms. The problem with hard-coded anything is it becomes a PITA to change. Always look for ways to tableize your workflow. It is ever so much easier to change a table than to change a form and have to move stuff around to fill in the gaps.

Call me old fashioned but I still like the switchboard style. I've updated mine to enable more than 8 items and even created totally new versions but that is my go-to menuing interface just because it is so easy to work with. My clients don't pay me to make stylish, complex interfaces. They pay me to make functional applications that someone else will be able to maintain once I move on. I make them pleasing to look at but functionality comes first. Cost comes second. "Slick" is nowhere in the list.

I have two sample databases with several options. One of the databases includes a minimal security option and the other is no security.

Replacement Switchboard

This Switchboard form is based on the last VBA version which I think was A2k. I expanded it to allow for 12 items rather than 8 and you can easily change it to do more. I've included directions. This updated version has two switchboards. One more traditional and the other is big buttons...

www.access-programmers.co.uk

Switchboard with simple security

This is a custom switchboard. It expands on the Switchboard Items table to add four additional columns to define view/edit/add/delete security levels for switchboard items and forms/reports referenced by them. It includes tables to manage users and also to assign them security levels. The user...

www.access-programmers.co.uk

It is probably too late to help with this app but they are something to think about going forward. The alternative, if you really want to stick with this style is to make your own navigation subforms. I don't recommend this though. The reason the navigation form doesn't nest more than one level is it just gets too hard to manage with a generic interface. If you code a custom interface, you will have more luck because your code is custom rather than generic.

 

[RobDuggan]

@Pat Hartman - thanks for your comments. Yeah 2 layers of Navigation forms seems to just be a bad idea.

For me I rate UI more then most access users, in fact in my case management have refused to allow us use access for new tools, however when I show them my UI they didn't even realise it was access so gave the go ahead when the can see that it doesn't have to be an ugly blocky UI.... of course this take considerable time and effort and I wish access had better tools for managing forms but you got to work with what you got.

Thanks

 

[Pat Hartman]

Access has many tools that no one bothers to use such as themes and templates called application parts. You can do exactly what you want to do with nested forms, although I do think the limit of nesting is 7 (it used to be 3). The thing is, you have to code them yourself. The Navigation form is a generic tool. Generic tools lack the flexibility of custom solutions.