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 Wouter Steenbergen, a PM on the Access team responsible for Access form and report designers.
If you want to build an easy to use application it always starts with a good navigation model that allows users to quickly perform the most common tasks and easily find the less common tasks. Years ago, Access introduced the concept of a switchboard manager which has become a mainstay for many applications in the late 90’s. The hierarchical model and ease of adding new objects into the interface served our community well for many years. However, advancements in web design and user interfaces have developed more intuitive interface models. When was the last time you saw a well-designed web site that worked like a switchboard manager?
Moving Access to the web was a great opportunity for us to re-invent the tools we provide to build navigation. It started with an exhaustive study of many of the top 100 web sites. A few patterns emerged: Web sites usually have top level navigation commands and often expose sub navigation directly below or along the left side. When users navigate the top level color and background images typically highlight to users what top level item is selected. It’s a useful paradigm that gives users sense of direction.
In Access 2010, we have implemented a new way to implement navigation; navigation forms. Navigation controls support the new look and feel functionality that Viki and Steve talked about in an earlier post. This guarantees many opportunities to create a great-looking web interface that is easy to understand and simple to use. Take a look at the Demo of Access 2010 room bookings database, Albert really summarizes the Navigation form well at the start of his video.
Here is a quick demo on how it works:
When you create a navigation form using one of six predefined layouts, it contains a navigation control and a subform control. These two controls are connected by the NavigationTarget property on the navigation control.
When you drag a form or report onto the navigation bar, a new button is added. Selecting the button causes the corresponding form or report to appear in the subform control.
Advanced Access users may notice that this implies that we removed another design limitation. In Access 2010 it is possible to render reports in a subform control on a form. This makes reports a truly integrated part of your web application.
After making your navigation form, you can set the NavigationWhereClause in the button’s property pane, to make the Navigation button automatically apply a filter when the button is selected. This makes it super easy to filter an existing view without creating different forms or queries.
The navigation control is accessible by using the object model. It’s not possible to dynamically add or remove tabs, but a lot of other properties are available.
You can show or hide buttons based on the role of the user by setting the visible property in an OnLoad or OnCurrent event. Other properties that are available on navigation buttons are Enabled, Visible, Locked, ForeColor, BackColor and Caption.
You can replace the look of all your tab buttons by selecting icons instead of typing in the button caption. This allows you to customize the look and feel of your navigation even more. In the example to the right, I used icons borrowed from Excel’s conditional formatting.
Some of the new shapes introduced in Access 2010 are specifically designed for use with navigation and tab controls. They’ll allow you to create a nice tab-like experience when designing your navigation.
Some people may wonder when to use a navigation form versus a tab control. The difference between tab and navigation controls is that the controls in a tab are part of the form. Individual tabs are hidden behind each other. The navigation control unloads and loads a new form (or report) in the sub-form control. This triggers record updates and requeries the data source.
If you are interested in learning more about how to build good navigation UI, I strongly recommend chapter 7 of Steve Krug’s Don’t Make Me Think: A Common Sense Approach to Web Usability.
Comments: (12) Collapse
Hi,
A couple of questions: Will these navigation tabs have an 'On Change' event that can be used with VBA? Quote: "You can show or hide buttons based on the role of the user" Can you please elaborate on the issue of 'roles'. Is this also a new feature or is it just some global variable that was used in code for the above example? Thanks
Gilad
Hi there,
have tried recreating this in the tech preview, but every time I drag a form on to the navigation control, as in the video above, nothing happens. I just get the circle with the line through it. What am I missing? Thanks oX.
>Will these navigation tabs have an 'On Change' event that can be used with VBA? No there is not a on change event. The forms on-load event does fire (so VBA could/would go there). I also found I could place a regular button onto the layout grid next to the nav control formatted to look exactly like a button from that nav pane. That button when clicked on can run code and do near anything you want. There is also a new "browse to" command that lets your code "change" the current form (or report) that the selected nav button is displaying. It is a very simple but great little control system. >Can you please elaborate on the issue of 'roles'. yes, that interesting to me also. I not seen that function either. It looks new to me. There is a function called IsCurrentWebUserInGroup(). I assume this function allows one to test/check for membership in SharePoint groups. IsAdmin does not look like a local var, and it don't look like a function either. My guess it is a new enviromement value that I not seen... I think the role issue and your question could be the subject of whole new article here
>every time I drag a form on to the navigation control, as in the video above, nothing happens. Hum, works for me. Try creating a blank form, and then choose the navigation option from the ribbon (with the choice of horizontal, or vertical…choose one you like) (don't place the nav contorl on the form...try using the ribbon option). Now, you should be able to drag + drop forms onto the nav control. Keep a bit of a careful eye on the orange bar that highlights the position where you control will appear. It very much like dropping a control onto a layout control in 2007. Make sure your form is layout view.
Gilad, we will write up a post on the CurrentWebUser() stuff. It isn't a replacement for user level security but rather a handy function for controlling the user interface for web apps. Can you elaborate on the scenario you had in mind with navigation tabs and OnChange? oXmike--are you trying to add client forms into a web form? That might be the reason you are seeing the can't drop sign.
Thanks Clint/Albert,
In my excitement I missed that I was using client forms. I'm wondering how many other people will miss that too when the final version is released. Maybe it should remain hidden till needed in the final version. oX.
oX. The navigation control is available for client forms. Assuming you are in a web database look under the Client Forms dropdown for a client version of the navigation forms. It is the option at the bottom.
>“Can you elaborate on the scenario you had in mind with navigation tabs and OnChange?” Clint, you asked me to elaborate, so here goes: First let me say that I think I have the same navigation ability as that of the new navigation control that you described above, but with a regular tab control. For me, what is missing from the tab control is only how it looks, which I was hoping will improve. You can’t change the back-color of a page on a tab control for example, (unless you use all sorts of improvisations which I don’t like and that are problematic). So here is how to reproduce the same functionality with a regular tab control: I have a continuous form. In its footer I have a Tab control. Over on top of the tab control, but not included inside any of its pages I situated a sub-form control (initially Access tells you that you can’t do that and automatically changes the top level form to have a single form view instead of continuous, but that can be then changed back to continuous). Once a user clicks on one of the tabs in the tab control, the tab’s On-Change event is triggered. In this event’s code I replace the content of the sub-form’s container to contain a different sub-form appropriate for that tab. But in addition to the functionality that you described for the new Navigation control, here this sub-form can also be set to continuous, and can have linked child and master fields to its containing form. So when adding new records to the sub-form, Access automatically takes care of inserting the correct PK field into the sub-form’s underlying table. It gets better because you can have the same thing repeated for a second level inside the sub-form itself. In other words this sub form can contain another tab with another sub form on top of it. So you can see on the same screen a hierarchy of three levels, one to many, and then again one to many. In order to repeat this with the new navigation control you would have to code all that Access does automatically with the child and master fields for sub forms. I guess you would have to use the sub-form’s before-insert event to take care of the PK field, and probably some more things also. The sub-forms underlying query will have to include a criteria that references the top level form in order to filter the records etc.. You wrote that the ‘roles’ only apply to web apps. If I understand correctly then ‘web apps’ are applications that are run on the browser and are linked to lists on sharepoint, and that do not require the user to have Access installed locally? If so, then it is unfortunate that roles only apply to web apps because I was hoping that there will be a way to handle roles for regular client apps as well. I still haven’t done that for my applications and need to do it in code. Web apps are great but I personally don’t think that they will completely replace regular client applications, but will mostly be an addition to them. So from what I can see, in terms of how it looks , this new Navigation control is a nice and welcome improvement when compared to a Tab control. But in terms of the functionality of a regular client application, I think it is a reduction in functionality when compared to a tab control. For me functionality comes first. Gilad
Gilad--thanks for the explanation. You will get the same visual formatting for the tab control. You just need to turn on the Use Theme property. We still don't allow you to set the backcolor of a tab page. Nice feature request.
Boy I wish this was in Access 2003 and 2007.. it should be so backward compatible, because tab control doesn't do all these things navigation control does.. which I'm glad you've added this because coding tab controls properly to deal with record updates/requeries and switch tabs is a pain with the tab control, you do have to know your logic well, and I find that header forms of subforms, tend to fire subform control current record many times in a row based on events that occur. So congrates on adding a cool new developer feature to make it easier to build better UI in no time flat!
Thanks MS!
I am using the Navigation tool and finding that it works pretty well. The issue that have is that when using a split form, the data sheet portion disappears. Is there something that I can do to get my data sheet component back?
What happens if an Access 2010 file with a navigation control is opened in Access 2007? Can the navigation control still be used in form view? Can the navigation control be edited in design view?
Comments: (loading) Collapse