Customizing the New Access UI

I described the new Access UI in this post and this post way back in March.  Now I'll run through how you program the ribbon UI using VBA.  In a future post (we're still working out the content) I'll do another post on how to do the same thing using macros (so the app will run in disabled mode). 

Customized Ribbons

The ribbon UI presents a ton of new flexibility for us creating Access and for you building apps on top of Access that wasn't there before.  As described in the posts on the ribbons, there are a lot of new control types that can be placed in the ribbon, and there's much more flexibility about how they are presented.  The downside to this additional flexibility is that the ribbons are more complex to create than the old command bars.  Building ribbons isn't beyond the reach of any successful Access user today, but it will take some more work.  The upside is that the end product can be significantly better.

Here's an example of an application with a customized ribbon UI:

(Click image to enlarge)

The app has a rich set of controls, including a dropdown to let different users log on:

And of course after each user logs on, you can fire code to both update the contents of the ribbon itself and to take actions inside the application.  Here is an example of the changes to the ribbon itself:

(Click image to enlarge)

The application can have multiple tabs, just as Access does, and the user switches between them just as in the regular Access ribbons.  Here's the Form ribbon:

(Click image to enlarge)

In addition, custom ribbons can use the full range of controls available in Access.  Here's an example of a dropdown button on the Reports tab:

And an alternate split button presentation for the same data:

Controls on the ribbons can how have "Super Tooltips" (not sure if that is the real name?).  These are extra large tooltips containing more, and richer information than the command bar style tooltips, but that launch in just the same way.

Customizing the Ribbon

There are 5 steps to customizing the ribbons:

  • Create the ribbon XML - the ribbon definitions are done through an XML file, and the first step is to build that file.  This is pretty easily done with a simple text editor, but can be made even easier with Visual Studio tools.
  • Specify callbacks - next, you need to build small VBA routines that handle ribbon actions like clicking a button or selecting something from a dropdown.
  • Create table for XML file - next, you create an Access table to hold the XML you created in step 1.
  • Add the ribbon to that table - next you create a record in the table for each custom ribbon, containing the ribbon name and the XML definition of the ribbon.
  • Set the Custom Ribbon property - finally, you set the Custom Ribbon property for the database as a whole or for specific forms and reports to load the ribbon you defined in the table above. 

Creating the XML Ribbon Definition

The ribbon definition is a simple XML file and can be easily created in any text editor, but if you're using Microsoft Visual Basic.NET 2005 Express Edition or Microsoft Visual Web Developer 2005 Express Edition, you can get IntelliSense for your code.  Visual Web Developer looks something like this:

(Click image to enlarge)

You can point it at the custom ribbon schema at http://schemas.microsoft.com/office/2006/01/customui and VWD should pick up the correct file, which is called customUI.xsd.  Alternately, you can download the file from http://officeblogs.net/UI/customUI.xsd

(Click image to enlarge)

This enables VWD to provide type-ahead IntelliSense for the correct ribbon xml.

(Click image to enlarge)

You can see the XML file for the sample application we're building by clicking here.  The contents of the file are:

  1. customUI - this is the top level element for a custom ribbon
  2. ribbon - defines the ribbon itself.  Set the startFromScratch attribute = "true" to create a new blank ribbon.  If this is omitted or left blank, the custom ribbon will merge with the existing Access ribbons.
  3. tab - creates a new tab in the ribbon
  4. group - creates a group (or "chunk" in my ribbon description post).  These are used to logically group controls in the ribbon.
  5. id - unique name of a control in the ribbon
  6. label - static text displayed with a control
  7. button - similar to a command button.  Use the onAction attribute to specify the name of a subroutine in the database which will be called when the button is clicked.
  8. dropDown - creates a dropdown list that cannot be updated.  To create a drop down that the user can type in, use a comboBox control instead.
  9. imageMSO - specifies the name of a built-in control in Office that can be used as in icon in your ribbon.

Creating VBA Call-backs

Next, you need to write the routines that are called by the ribbon when an action is performed.  Here's what to keep in mind when writing these routines:

  • You'll need a reference to the Microsoft Office 12.0 Object Library
  • Arguments to Sub routines are fixed
  • In many cases, you can use a single routine for many events.  For example, you might have a single subroutine that handles opening forms in your database using button controls in the ribbon.  The tag attribute in the button can be used to store the name of the form, and the generic routine simply opens that form name.  For example, such a routine might look like this:

Public Sub onOpenForm(control as IRibbonControl)

    ' Open the form which is specified in the tag attribute

    DoCmd.OpenForm control.Tag

End Sub

  • To refresh the ribbon, call the Invalidate method on the IRibbonUI object.  This object is passed to you in the onLoad callback when the ribbon is loaded.  You can save an extra copy of this object to use as needed:

' Cached copy of the RibbonUI. Used to invalidate the ribbon to

' refresh controls.

Public gobjRibbon As IRibbonUI

 

' customUI onLoad event handler

Public Sub onRibbonLoad(ribbon As IRibbonUI)

    ' cache a copy of the Ribbon so we can refresh later

    Set gobjRibbon = ribbon

End Sub

 

' Then, to refresh the entire ribbon, call:

gobjRibbon.Invalidate

You can look at the macros in this example database to get a better idea of the code to write.

Creating the Ribbon Table

Simply create a table in your database called USysRibbons.  This table should have 2 columns:

  • RibbonName - type: Text(255)
  • RibbonXML - type:  Memo

The table should looks something like this:

Adding the Ribbon XML

Now simple create a record for each ribbon you'd like to create in the table above.  Note that this is already done in the image above.

Set Custom Ribbon Property

Next, you go to the Access Options dialog and under Toolbar Options, choose the ribbon for the selected object.  Again, you can see these settings most easily in the attached database. 

Tips, Tricks, and Additional Information

Here are a few general things to remember:

  • If you use VBA callbacks, the database must be opened in enabled mode for the code to run.  You may receive an error in Beta 2 when opening a database with custom ribbons in disabled mode.
  • Set a reference to the Office 12.0 Object Library to use IRibbonControl.  You'll get a compile error if you don't have the reference included.
  • Elements and built-in names of controls and images may change prior to release.
  • To edit the ribbon, and XML editor such as Microsoft Visual Basic.NET 2005 is quite handy.  The Express Edition works great.
  • Show system objects in the nav pane to modify the USysRibbons table
  • You can hold down the SHIFT key when opening the database to open it with the Access ribbon rather than your custom ribbon.  However, this doesn't work in the Beta 2 build (sorry about that).
  • You can show errors in the UI XML by turning on an option in Access.  If you open the Office menu (the round button), and select Access Options / Advanced  and then check "show user interface errors", Access will show a dialog describing any problems in the Ribbon XML.  The dialog will look something like this: 

         

For additional resources take a look at these sites:

Next Time

The next post will be the first of several drilling down into using Access in conjunction with Windows SharePoint Services.

 

Office Blogs Comments

Comments: (46) Collapse

  • You know, I always thought that the ability to customize and move toolbars and menus in previous versions of Office was one of the coolest features around. And once you got the hang of it, it was quite easy! It afforded both developers and end users great flexibility. Now it is basically being taken away for a new paradigm. I think the Ribbon concept works well in some of the other apps like Word and Excel, but for me the same does not hold true within Access. So why in the world would you kill it completely? Why not have it be optional, even be the default, but still have that great customization of the old mode as an option? I also think its a big mistake to not have the ability to easily customize the ribbons. I just can't believe that it would be that great of an effort to offer some kind of basic tool to do this. NO:

    -ULS

    -Toolbars or menus

    -No replication

    -No optional (i.e. old style) view with the Nav pane

    -No further support of ADP's (they appear to be basically dead) I understand that a huge effort has been made to add some significant features to Access. I appreciate the hard work that has gone into it. But as a long time developer of Microsoft Access applications, I am truly disappointed..and baffled.

  • StepUp, You're not the only one disappointed. Despite the really neat results achievable with gridlines and layouts, this menu issue is going to dissuade a lot of developers from considering this product further. Why isn't Microsoft forcing this new paradign on Visual Studio? Why are they shoving it down the throats of Access developers, and not Visual Basic developers. If they did, you would surely hear howls from developers using that tool. You heard it here first: Access 2007 is the "new Coke", a fiasco that resulted in Classic Coke. For pity's sake, Microsoft give us a way to incorporate customer menu and toolbars a l a

    Access 2003. Just my 2 cents. Bob

  • Conclusions: 0) Icons included in the Office library are not never useful 1) Our custom icons must reside externally... ????

    2) We must write code to specify the wishes icon in the ribbon.

    3) There isn't a Visual Editor in Access 12 for Ribbons manipulation There are no words: it was much better Access 97! You must consult who REALLY develops application with Access, before working on the new releases of product. You have mistaken many things in this version 12: some new features are amazing (new report engine: great!), other are annoying and much dangerous. Microsoft Ribbons? RAUS!

  • "You must consult who REALLY develops application with Access, before working on the new releases of product." I agree with that sentiment. Supposedly, developers WERE part of the early testing groups, but I find it hard to believe that there was a true representation of folks who are really serious developers. I can not imagine any developer, especially those that do it for a living like myself, who would be happy with options being taken away and crippling some of the great capabilities of past versions of Access, in spite of some of the new cool features. BTW, another thing that I am not happy with is the basic look of the forms. I guess these XP theme styled type of forms are OK with many people but I prefer the classic Windows form style. I like a basic, clean look that uses screen real estate efficiently. AGAIN and AGAIN I have been asking myself, why take away this and other options?? Yes, Access is an end user tool, but it also is a SERIOUS development tool. Developers want options, so they can develop in whatever style they choose. As someone in this thread pointed out, can you imagine the reaction if Visual Studio developers were forced to use Ribbons and could not fully control the look and feel of there apps? A second BTW: I followed the steps outlined earlier in this thread for removing the ribbons, but it did not work. Anyone else try this?

  • Zen/DataMouse/Stuart,

    I must not have made myself very clear. If you are using an ACCDB database you can put images in an attachment control and using a hidden form and a few lines of code load them into the database without having to have the files stored externally. It doesn't work in beta 2 but we will have code samples in beta 2 TR. For MDB or ADP users you can store the images in binary fields and save them in a temp directory. I expect we will have code samples of this as well. StepUP,

    There was a slight change in the casing of the ribbonXML that caused my sample to not work. I have uploaded a Db with a working sample of startFromScratch. WRT - the basic look of the forms. You can still use the old windows 3-d style in your databases. There is a property under Access Options | Current Database called Use Windows-themed Controls on Forms. This should give you the old-style look if that is your preference.

  • Sorry folks, I forgot to include the link to a database that has the start from scratch working correctly. I need to go home and start this day over :-). clintc.officeisp.net/.../36 - Ribbon Extensibility/StartFromScratch.accdb

  • Clint Convington: "For MDB or ADP users you can store the images in binary fields and save them in a temp directory..." Question: have you never used Access in order to develop applications? What do you think about R.A.D? Do you know the Access Runtime version and the "lost references" bugs of package wizard?

  • Clint, You link is incorrect. But I got to the file by going to clintc.officeisp.net/Blogs and then clicking on "36". Anyway, when I tried to DL the "StartFromScratch.accdb" it asked for a login. Can you correct this please? Thanks

  • zen: Do you know the Access Runtime version and the "lost references" bugs of package wizard? I am not sure exactly what bug you are referring to. A known limitation of referencing libraries is that you need to compile for the lowest common denominator. If you do development in Access 2003 and you want people to use the Access 2002 Runtime, you need to go to a machine that only has Access 2002 and make sure that your application works properly. This may mean deleting missing references to future libraries and adding back references to previous libraries. Once you have confirmed that it works correctly, you can deploy that copy of the database. If you open that database in a newer version of Access, that may cause your referenced to be bumped to the newer libraries that are installed. That is why you need to make sure you test on the lowest common denominator as the last step before deploying. References should always be forwards compatible (old references work for new libraries) but they are not always backwards compatible (new references may not work for old libraries).

  • Here is a link that should work for the start from scratch database... clintc.officeisp.net/.../36%20-%20Ribbon Extensibility/StartFromScratch.accdb

  • Tim Getsch: "I am not sure exactly what bug you are referring to" Problems of "missing references" always have been frequent with the Microsoft package: as an example with access 2000 Runtime the recording of ADO libraries did not work well. Beyond to the famous conflicts with other versions of Office preinstalled. The only solution is to buy the sagekey scripts: www.sagekey.com Do you promise to give us a "rock solid" Runtime package for Access 12?

  • clintc.officeisp.net/.../36 - Ribbon Extensibility/StartFromScratch.accdb Nope....Still doesn't work.

  • I missed a space. Does it not work if you don't paste in the entire URL from http to accdb? clintc.officeisp.net/.../StartFromScratch.accdb

  • Clint, Yes, that worked. Thanks. Only problem is....if I design an app that I don't want ribbons for for the end user, I might still like to have them for the design of the app (well, really I'd rather have tool bars that I can easily customize to my liking), and it makes it that much more difficult to switch back and forth. My point is, at the risk of being redundant, I think Microsoft is making a big mistake in not offering a tool to customize ribbons. It was always there for toolbars. Aren't Word and Excel users expressing the same concern?

  • > My point is, at the risk of being redundant, I think > Microsoft is making a big mistake in not offering a tool to > customize ribbons. It was always there for toolbars. > Aren't Word and Excel users expressing the same concern? We are hearing similar feedback on this issue but the overall response to the ribbon has been very positive. There is interest in building customization UI but that didn't get done this release. In the Word and Excel case the most common scenario for heavy toolbar customization by developers is companies that build addins. From what I understand, they are doing great things with RibbonX. Access is a bit different because developers build apps that control more of the UI than the other applications more often. The PM team has been thinking about putting together a database that will generate ribbons. The ribbonX schema isn't that difficult to where a tool would be hard to create. In fact, we had a database that generated ALL of the Access ribbon XML. Our internal format is bit different than the external format so we can't just provide our database. I also expect some third party addin people to do some interesting stuff here. After beta 2 TR ships I will post a database that has custom ribbons without any code. It took me less than 2 hours to build. Once you have an XML editor and the XSD--it is really easier than you think. My guess is most beginners will simply start from a sample and tweak the labels, icons, and functions. I think most developers could be pretty productive in a couple of hours playing with the XML once they have some good examples and help documentation. There have been some questions about RAD on this thread. After using Access 2007 for the 1.5 years to build all our templates--I couldn't stand to go back using 2003 because the new product is so much easier to use. It has been our experience from personal use and usability research that developers are far more productive than before. Would we like to have shipped customization UI--you bet! However, I think it is more important to develop a super stable base and nail the user experience around the ribbon.

Comments

Comments: (loading) Collapse