Last week the team was privileged to host our MVPs at a conference here in Redmond. During our in-depth talks about Access 2010, some of these MVPs asked me about the new DoCmd and macro action called BrowseTo that we’ve introduced with Access 2010. I’ve written this post to demystify this strange new action.
In short, BrowseTo allows you to create web-style navigation between forms and reports.
We’ve already talked about the navigation control. The navigation control allows you to easily create tabbed navigation hosting sub-forms and sub-reports.
BrowseTo operates similarly but is much more flexible. BrowseTo is the navigation control’s big sister. It allows you to roll your own navigation or build custom UI on top of an existing navigation control.
Let’s show a simple example of BrowseTo in action.
This wizard asks the user to step through a series of forms. The “Next” button disposes “Step 1” form and loads “Step 2” form in its place. Here’s what the OnClick event of the Next button looks like:
Let’s take a look at each of the non-NULL parameters.
- Object Type: “Form”. Alternatively, this could be “Report” if we were looking to load a report.
- Object Name: “Step2”. This is the name of the form or report to load.
- Data Mode: “Edit”. “Add” and “Read Only” are the other options. These are the same options available for the familiar OpenForm action.
BrowseTo operates by browsing from Step1 to Step2. It works just like a hyperlink.
The Address Book
Now let’s look at a more advanced example. Lois, one of the PMs on the team, designed the 2010 Contacts template around a main Address Book view of contacts. It lists all the contacts down the left side of the page. With one click, the contact’s details are presented in business card in the center of the page. Pretty cool!
How is this done? The list of contacts on the left side is a continuous form. The textbox that contains the name of the contact has an OnClick event. The OnClick event loads the Name Card form and filters to the appropriate contact.
Let’s take a look at the rest of BrowseTo’s parameters introduced by this example.
- Where Condition: “[ID]=[TempVars]![tmpID]”. This is the WHERE condition to apply to the form or report we load.
- Page: “”. Although not relevant for this example, BrowseTo can be used to drillthrough to a particular page of data in a continuous form.
- Path to Subform Control: “Main.NavigationSubform>ContactCard.DS”.
The Path parameter is the tricky part. There are three techniques for using the Path parameter. Let me describe them before returning to the example.
- Just like a hyperlink: If BrowseTo is called from a “top-level form” (a form that is NOT within another subform) and if the Path parameter is left NULL, then BrowseTo operates just like a hyperlink. The current form is disposed, and the form specified in BrowseTo is loaded in its place. This is the technique used in the wizard example.
- Change my parent subform control’s SourceObject: If BrowseTo is called from a form that is hosted within a subform control and if the Path parameter is left NULL, then BrowseTo leaves the parent form in place and changes only the contents of the current subform control. The current form or report is disposed, and the form specified in BrowseTo is loaded in its place.
- Change the SourceObject of an arbitrary subform control: The Path parameter allows you to control the SourceObject of any subform that is currently visible in the application.
We utilize this third technique in Contacts. Path is set to “Main.NavigationSubform>ContactCard.DS” This means that Access is instructed to load the NameCard form inside the DS subform control of the ContactCard form. ContactCard, in turn, is loaded inside the NavigationSubform subform control of the Main form.
If the “>” character seems unusual, that’s because it has been introduced specifically for the Path parameter of BrowseTo. Its meaning is this: The form to the right of the “>” character is loaded into the subform control specified to its left.
When you’re developing a database using BrowseTo, you may occasionally run into this error message:
Here are some tips for resolving this error message:
- The path must specify a series of Form.SubFormControl pairs. Each subform control specified must be a control in the form that precedes it in the path.
- The pairs must be separated by the “>” character.
- The first form in the path must be the form that is currently loaded directly in the Access window (or browser window if the application is running on the web.) This means that the Path parameter only allows you to change the contents of a currently-visible subform control.
If you’re using Access 2010, experiment with BrowseTo and give us feedback.