Build navigation UI with Access 2010

re: Build navigation UI with Access 2010

David — Tue, 08 Dec 2009 15:11:51 GMT

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?

re: Build navigation UI with Access 2010

Gelert — Tue, 01 Dec 2009 21:59:14 GMT

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?

re: Build navigation UI with Access 2010

Dennis Yapp — Fri, 20 Nov 2009 02:58:54 GMT

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!

re: Build navigation UI with Access 2010

Clint Covington — Thu, 19 Nov 2009 02:11:58 GMT

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.

re: Build navigation UI with Access 2010

Gilad — Tue, 17 Nov 2009 08:10:26 GMT

>“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

re: Build navigation UI with Access 2010

Clint Covington — Mon, 16 Nov 2009 17:10:29 GMT

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.

re: Build navigation UI with Access 2010

oXmike — Mon, 16 Nov 2009 16:43:17 GMT

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.

re: Build navigation UI with Access 2010

Clint Covington — Mon, 16 Nov 2009 15:06:52 GMT

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.

re: Build navigation UI with Access 2010

Albert D. Kallal — Mon, 16 Nov 2009 03:48:58 GMT

>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.

re: Build navigation UI with Access 2010

Albert D. Kallal — Mon, 16 Nov 2009 03:42:59 GMT

>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