Is it possible to prevent MS Access from changing the selected ribbon tab automatically when using a custom ribbon?
When a custom UI XML file is used to add several custom ribbon tabs in Access, the selected ribbon tab changes back to the first custom tab whenever a form is closed.
We load a custom ribbon programatically from VBA. I've create an accdb that reproduces the problem. The folder also includes an XML file that contains the ribbon definition. It must be in the same directory as the .accdb file.
The problem can easily be demonstrated:
- open the database RibbonTest.accdb,
- switch to Tab2 and open Form2 using the button on the ribbon and
- close Form2.
Notice that Tab1 is now active.
Of course, in this small example db this problem seems very minor. However, we have a very large project with many custom tabs, each containing numerous groups and buttons. Our users are finding it very frustrating indeed that they keep losing their place on the ribbon every time they close a form.
We have investigated a workaround where we programatically store the selected tab and restore it when we think we need to. However, it is proving difficult to do this reliably. (There isn't an Office API for automating the ribbon like this, but this article helped.)
Has anyone else encountered this problem? Have you found a way to prevent the tab from changing automatically?
Edit: It seems that this problem was introduced with a fix implemented in Office 2010 SP1 . (Sorry, no link: don't think I can have more than two.) The problem is not present in the RTM version. The fix list for SP1 includes this: "Access does not activate or return the user to the correct Ribbon tab for a previously opened database object when the user returns to that object." It seems that they've tried to fix use of the Form.RibbonName property (which supports contextual ribbons), but have broken the default ribbon in the process.
Answer
This one line fixes the issue:
<tab id="tabBogus" label="Bogus" visible="false"></tab>
Just make it your first tab in <tabs>. Big thanks to Scott's Potential Workaround answer!! (Tried to Vote it up and/or comment, but just signed up so not enough reputation.) This saved hours (or days) of work versus the other complicated workaround! Thanks!