You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Tips
How-to
News
Videos
Stories
Today’s guest writer is Steve Greenberg, a Lead Program Manager on the team. Steve is responsible for form rendering and the new templates in Access 2010.
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.
Wizard
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.
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.
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.
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:
If you’re using Access 2010, experiment with BrowseTo and give us feedback.
Enjoy!
Comments: (20) Collapse
This looks really good. Is it possible to combine it with clicking a control on a report in report view in a web database? I have some reports which open in a navigation form and would like to be able to click on one of the records to open a form, also in the navigation form, with records showing according to a filter criterion. From what you have shown above, it should be easy to do from a continuous subform, but with a report there are no clickable events, just the possible use fo a hyperlink.
If I have to convert the report to a continuous subform, then that will be no great hardship, but reports format nicely and, if it were possible, I would like to keep using a report.
Thank you very much, Steve, for the explanation, which helps a lot to understand how it works. However, I am still struggling to see the purpose. In both of your examples, the same functionality can of course be easily achieved using "old" ;) methods/actions. Are you able to provide some follow-up examples to illustrate where BrowseTo provides a significant advantage.
Would it close the existing window (form) when Browsing To the next? If so, that is different functionality than a simple hyperlink.
Worked well for me once I got my head around what the bits in the Path meant for me in my app. Am looking forward to seeing it work when published to Accesshosting.com.
Thanks for the comments, Alan. You're correct that the OnClick event is not available in web reports. So you're only option is to use a hyperlink. In my next post (coming shortly) I'm goign to deconstruct the URLs that Access Services uses. By building up a particular URL, you may be able to get the drillthrough behavior you want. To use an OnClick event, you'd have to switch over to using a continuous form.
Hi Steve, This is a great question. Thanks. There are ways to accomplish these scenarios without BrowseTo. But BrowseTo was specifically designed from the ground up to work identically in the client and in the browser. (I'd be interested to hear which specific methods you would choose. With that information in hand, I can probably tell you the pros/cons of using your methods in a web database.) Here are two unique values that BrowseTo supplies: 1) It's a macro action that works in the client and in the web. No VBA is necessary.
2) When you use BrowseTo in a web database, the URL for the user updates whenever the state of the application changes. This means that the Back, Forward, and Refresh buttons of the browser work the way the user will expect. More on this in a subsequent post.
BHicks, It reuses the existing window. This is equivalent to most browser's treatment of an tag with the target attribute unprovided. --steve
Steve, Thanks for your reply. Well, in response... In the Wizard example, any problem with a combination of OpenForm and Close actions? In the Address Book example, in a desktop application I normally do stuff like this by toggling the RecordSource of the DS subform, which in a macro would I suppose be best done with a SetValue or SetProperty action. I know that others would sometimes prefer using ApplyFilter. What is wrong with these? Thanks.
Can we download this Address Book 2010 template?
Hi Steve, In the wizard example, if you do a Close first, the browser window will close and the code to call OpenForm will not run. One of the differences between the browser and Access is that in the browser there's no parent process that keeps running code even if the current form is unloaded. In the Address Book example, you'll find that the set of properties that are settable via SetProperty is limited in web forms. RecordSource is unfortunately, not settable. ApplyFilter can only be used to apply a filter to the current form or to a subform within the current form. In the Contacts application, the continuous form on the left and the ContactCard on the right are both children of a parent navigation form. So that unfortunately won't work BTW: One solution with ApplyFilter that would work on the web is to use a listbox rather than a continous form. Thanks for your comments. This has been very interesting.
Hi John, Yes. The Address Book is available. In your copy of Access, choose File | New | Sample Templates | Contacts Web Database. Let me know what you think, -- Steve
Hi Steve S. In addition to other comments here it often not understood that in theory a open form command should launch a whole form as a new browser window. However if each form resulted in a new browser then you have no way to get back to the previous form. I have a presentation called “access web pain” in which I demonstrate this issue. I call these forms runaway forms! It is great simple mind set change that so many of us not really thought about when jumping to the web. The funny part is this is like trying to explain how to ride a bicycle. We learned how forms open and launch so long ago. We not had to change or think about this forms issue for many years when doing desktop development. Browseto command simply allows you to force the browser to “move” or browse to another form in the browser (and that is why it has a where clause). The regular OpenForm command executed in the browser results in a child form displayed like any form launched inside of regular ms-access. That form launched becomes a MDI form (or simply a child form of the current browser instance). Using OpenForm means there will be no back web button. You will see the form as separate form in the current browser window as a child window. Which child form will the back button on the browser now work on? In a nutsheel the form to form to form model breaks down very fast in web based applications. To browse to a form and make the WHOLE browser the whole form and not a child form, then we will use the browseto command. This means we have nice choice for access behavior when a form is launched. For a real web like experience we often don’t want a child form to pop up in the browser when we click on a button. We want to “browse to” that new form. And we can use this browse to with reports also. I expect we will fast start to use the browseto command in place of launching a child forms. We are not really wanting to launch new forms all the time, but what we want is to “browse to” the new display. So, this also points out that the browseto command is correctly named. We still have the OpenForm command and it works much as one would expect. Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Hello there. I wan't to ask if the BrowseTo command works only at Navigation Forms that are build for Web.
I'm asking this because I've build a navigation form but not for Web. I know where I wan't to go and wich form to open but an option is missing.
at the BrowseTO command Object type is Form, Object Name is "Clients", "Menu" is my Navigation form ,"NavigationSub" is my subform and inside my "Clients" form there is a control tab called "TABS" where I have 3 pages, 1 page is "Details", this is my final target.
At the Path To Subform Control I use: "Menu.NavigationSub>TABS.Details" I have tried everything.
I have taken the Contacts Database sample web database and gone step by step.. my conlusion is that something is missing , I will explain.
At the web naviform from Contacts database the target is the "NameCard","Main" is the main form, "NavigationSubform" is the subform all the above I have at my Naviform. What I don't have is "ContactCard" and "DS". Don't know ifthe above helps.
Thanx
Hi Albert, Thanks for that explanation. It's right on. Note that sometime between Beta and RC, we made a tweak to OpenForm. There used to be two WindowMode options for OpenForm. You could both kick off a new browser window and launch a dialog *within* the current browser window. We heard feedback that the new browser window approach was not very useful, so we removed it. OpenForm can only be used to open dialogs now. - Steve
Hi Savvas, I think I know what's wrong in your example. Let's take a look at your path: "Menu.NavigationSub>TABS.Details" The problem is "TAB.Details". Referring back up to the blog post, here is one of the requirements for path: "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.". So path must be a series of NameOfForm.NameOfSubFormControl. Given your description, it sounds like TAB.Details is actually a NameOfTabControl.NameOfPageInThatTabControl. Path doesn't support this. Let me know if that helps.
Comments: (loading) Collapse