Full Version: Navigation Form
UtterAccess Forums > Microsoft® Access > Access Forms
I'm playing around with the new navigation form it looks nice and should be slick to use. My problem is I use Openargs to modify how my forms open, even re utilizing the same form for multiple functions. I can't seem to find a way to use openargs or any other way to discern what navigation
Any ideas?
Have you tried using the Switchboard Wizard in Database utilities? The code behind that might give you some good ideas, all the options are based on values in a table that you customize for your particular purposes using stuff such as the open arguments.
I used switchboards for many years, and that is a normal route for me to use. I seen the navigation forms and wanted to give them a shot. Plus My enterprise if finally using SharePoint and navigation works well with SharePoint.
Thanks for the idea, keep 'm coming.
Fair enough Ed, just so I understand your vernacular (don't often get to use that word), could you explain what you mean by navigation form, its a rather ambiguous term to me....
NP, In 2010 Access now has Navigation forms in place of switchboards.
They are pretty and clean, they are web friendly (ie sharepoint). the problem is that they don't appear to be created in access like the switchboard, they appear to be a hard coded option and hence the ability to manipulate them is diminished. I was hoping someone has developed with them enough to find some tips/tricks when dealing with them. Looks like I might have to go back to the switchboard or my own navigation, was just hoping to use this new tool.
Ah gotcha, I am an old school 03er still.
hey look similar to tab controls, could you have there captions and 'Navigation Target Names' be filled in by looping through a recordset from a table much in the same way the switchboards work, basically adapting the switchboard code so instead of looping through 6(ish) buttons and labels, it loops through 6(or whatever) tabs filling in the relevant info and binding it to the relevant form or table hiding the unused ones?
Sorry if this was an obvious solution you have already considered and dismissed....
While it does look cool, I'll have to wait till summer (when my place of employment skips over upgrading to 2007 and goes to 2010... in 2011... from 2003...) to play with it. For now, I'm playing with using treeview for navigation of sorts.
A good way to approach this issue is to setup some custom properties of the form in question.
So, perhaps lets assume you used openArgs to open a form in two modes:
Mode1: Normal data edit
Mode 2: History mode (displays history data, no editing allowed and several other settings requited.).
The above would thus be a typical duel use of a form. Ignoring that you can open a form in read only mode via openForm, lets just assume we need quite a few different things to show and display and prevent things like delete etc. when you open a form for history mode editing.
So, for regular open you used:
docmd.OpenForm "frmEditInvoicing"
And, to open that same form in "history" mode, you went:
docmd.OpenForm "frmEditInvoicing", OpenArgs:="History"
Then of course in your forms on-load event, you test/check if the form is to be used in history mode as opposed to regular mode.
If Me.OpenArgs = "History" then
    ' code here to setup form in histry mode
End If

Of course, when you use the new Navgation control, then you not using openform anymore, but are in fact using a new command called BrowseTo.
What I suggest as a work around is to simply build and expose a property of the form as public. So, in place of using Openargs, you have to do this in two steps:
docmd.OpenForm "frmEditInvoicing"
forms("frmEditInvoicing").HistoryMode = "history"

In the forms code module, you will have written the following code:
Public Property Let HistoryMode(strMode As String)
   ' code here to setup form as histry mode
End Property

So, now we can open a form in code, and set the form into different modes, we just not be doing this in the open args and code will not be in the on-load event anymore.
In the case of using the navigation control to open that form, you would thus go:
DoCmd.BrowseTo acBrowseToForm, _
"Form to open", _
"Navigation Form.NavigationSubForm", _
"where condition"
So, in our case we go:
DoCmd.BrowseTo acBrowseToForm, _
                      ""frmEditInvoicing", _
                      "Navigation Form.NavigationSubForm"

Note how in the above we do have a where clause, so at least you can easy filter/open a form to a record with browseTo.
So, browse to will now open the form, and then the next line of code would have to set the forms mode into history mode. That line of code would be:
Forms![Navigation Form].NavigationSubForm.form.HistoryMode = "History"
I would say that exposing a property of the form like I did also opens up some interesting possibilities since your designs can thus have multiple instances of the same form open. Note that even before browseto command if you wanted to have multiple instances of one form open and active then you had to give up use of openArgs.
So, the property idea much treats the form more of a object (which it is), and you thus reference and use and set properties of that object as opposed to the idea of "passing" something to the form by OpenArgs. There are additional benefits of building and exposing custom properties of a form. One great advantage is that you can use/set/call those forms properties any time you want after the form been loaded, were as openArgs is quite limited and must be used at openform time. And it really hard to pass multiple values with OpenArgs unless you resort to fancy string parsing etc.
So this concept is more of an OO approach to programming in Access and it does work rather well as an alternative to OpenArgs.
And of course all of this works in 100% VBA applications, and it really lets you write applications that feel not only modern, but also feel more web like and this is how most desktop software is starting to look and function anyway:
THere is the nav control screen shot for those who not seen this:

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Ok, So I've poked around with this for a few days now and searching for other resources as well. I'm still unable to follow your instructions I'm lost on how to manipulate the "Where clause" in the navigation form to be of value. I've tried many formulas and trying to assign a value to a field and such but I'm not understanding how to use it properly.
Thank you for the explanation I'm sorry I've not be able to comprehend all of it. Are you able to help expand how the where clause and the new property work and are set?
Actually the where clause works exactly as it did before Even when using the new browse to command.
The only issue here is exactly WHEN are you prompting or asking or gathering the particular information that you plan to use in that where clause?
Omean I'm kind of under the assumption that in most navigation or switchboard forms, you're going to have a series of main forms that the user selects. However, at that point in time (just like the old Switchboard), you not really yet asked the user or have a need to filter the form.
I assume with the new navigation control, the user can simply click on one in the several options that you display on the main nav control menu.
At that point perhaps the form is some type of search form. Or the form prompts the user for some type of customer account number to look up. At this point in time, there's absolutely no reason to use the browse to command. You can use the standard open form command. If you do this, then that form launched will simply open up on top of the navigation form. The assumption here is we are running in tabbed mode.
When the user closes the form, then you be right back to the navigation form.
So you have a choice here:
Do you want to launch a form on top of the navigation system, or you want to launch a form inside of the navigation system?
If you want to launch a form on top, then use open form, when the user closes the form, you'll be returned right back to the main navigation form.
However you might not want to have to have the user to close the current form, but you want the navigation system to remain in plain full view, and for the user to go back, you now want them to click on one of the main menu options that remain in full view.
So here's what the code looks like for the two choices, And let's assume that the first main form that displays in our navigation system has a simple text box on it that prompts for customer ID along with a edit Customer button,.
The code behind the button on this form (we not talking about code behind nav buttons, but a form in the navagaton system)
So the simple form could have a text box and a button to edit a customer
The code could be:
Dim        strWhere   as string
Strwhere = "CustomerID = " & me.txtSearch
Docmd.OpenForm "frmEditCustomer",,,strWhere

So the above is classic access VBA code.
HAs I stated, this form will simply launch on top of the navigation form. The user edits particular information, and then they close that form (and if you turned off tab, you need to supply a close button on that form). When they close this form, then they will be returned right back to the navigation form (So the form will open up on top and hide your main navigation system form).
However you might not want to open the form on top, but you want the form to become the current visible form in the current navigation button that you've selected.
So, In place of open form, simply replace the above code with browse to
You get:
Dim        strWhere   as string
Strwhere = "CustomerID = " & me.txtSearch
DoCmd.BrowseTo acBrowseToForm, _
                      "frmEditCustomer ", _
                      "Navigation Form.NavigationSubForm", _

Notice in the above how my where clause is exactly the same syntax and setup as the open form command. As I stated, open form or browse are much functionally equivalent.
Keep in mind however if you use browseto, There's two significant issues and concepts to keep in mind:
If the form specified is not part of the navigation control set, then the current form your are viewing will be replaced with the form you specified. This also means to return backwards, the only way I'll be able to do this is have the user click on the currently highlighted navigation button which of course will still currently be highlighted.
If the form edit customer as specified in the above exists in any of the navigation form choices, then that Navigation control button will automatically be highlighted, and that form will be displayed Along with your where clause. (so we will swtich to that form in the navagation system).
So just keep in mind one of two things is going to happen in the above. As noted, you probably don't want to use browse to in the case that the form is not attached to a particular navigation control, However for many users today, they will not look for a close button, but will simply click on the navigation button (that is already highlighted) to return and re-display the search form for example.
So just keep in mind, that browse two means that your intention is to keep the navigation system in full view of the user. On the other hand if the form is such that you click on something and you want them to finish their work and what they're doing, it's probably better to use openform, so they don't get confused and click on one of the navigation buttons when they are the middle of one of your forms and they have not yet completed all the data entry.
So the syntax as to how you use the where clause does NOT change here, but you simply substitute the browse to command as per above.
However, your original question was not about the where clause but was about using open args, which as I mention you do not have, but I gave some workarounds as per above.
Try a simple test navigation form, and on a test form you add to this nav control, place a button that launches a form using openform, and then another button that launches a form using browseto. You will then a feel for how they behave differently.
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.