I believe that I've uncovered a bug in the implementation of the visible attribute of the separator element. Or rather, the fact that you cannot set the visible attribute to false.
The code I used to test this was as follows:
XML code for an Excel xlsm file:
[xml]
Code in the Thisworkbook module:
[vb]Private pRibbonUI As IRibbonUI
Public Property Let ribbonUI(iRib As IRibbonUI)
'Set RibbonUI to property for later use
Set pRibbonUI = iRib
End Property
Public Property Get ribbonUI() As IRibbonUI
'Retrieve RibbonUI from property for use
Set ribbonUI = pRibbonUI
End Property[/vb]
Code in a standard module:
[vb]Private bDebugMode As Boolean
Private bDynamicSepVisible As Boolean
'Set the RibbonUI to a workbook property for later use
Private Sub captureRibbonUI(ribbon As IRibbonUI)
bDynamicSepVisible = True
ThisWorkbook.ribbonUI = ribbon
End Sub
'Callback for rxbtnDynamic onAction
Sub rxchkDynamic_click(control As IRibbonControl, pressed As Boolean)
If bDebugMode = True Then Stop
bDynamicSepVisible = pressed
ThisWorkbook.ribbonUI.InvalidateControl ("rxsep02")
End Sub
'Callback for rxsepDynamic getVisible
Sub rxsepDynamic_getVisible(control As IRibbonControl, ByRef returnedVal)
If bDebugMode = True Then Stop
returnedVal = bDynamicSepVisible
Debug.Print "Separator visible property set to " & bDynamicSepVisible
End Sub
'Callback for rxchkDebug onAction
Sub rxchkDebug_click(control As IRibbonControl, pressed As Boolean)
bDebugMode = pressed
End Sub[/vb]
Upon saving all that and opening the file, you get a really ugly little group on the Home tab that looks like this:
Now, the interesting things here are that the first separator has it's visible property set to false. So why is it showing? The second separator is hooked up to the "Show Sep 2?" checkbox to make it dynamic. Uncheck it and the separator will stay there. I only hooked both up as I wanted to check if having the attribute set to static or dynamic would make a difference.
Finally, the Debug Mode is just there to allow you to see that the code does trigger and step through it while firing if you want to. (It also logs the value of the property to the immediate window, but this saves you looking there.) The entire Debug Mode and debug.print section could be dropped from the example, but then the checkbox doesn't appear to do anything. (As compared to doing something but being ineffective!)
I don't know how much this attribute would even be used, but the fact is that it doesn't work as advertised. I'm going to log this one with Microsoft. 🙂
4 thoughts on “RibbonX bug – separator visible attribute”
I am having a similar problem with getVisible callbacks on tabs. I am creating a ribbon with startFromScratch=true so that when clients are using my workbook, I can limit their functionality. I have built a ribbon that was working well. However, while we are developing the workbook we want some of the other built-in tabs to be visible that are hidden, but I can't them to toggle. Groups and custom tabs work fine, but not built-in tabs. In this simple example, the Insert and data tabs should show up but they don't. Any suggestions?
RibbonX
VBA
Dim MyRibbon As IRibbonUI
Sub OnLoad(ribbon As IRibbonUI)
Set MyRibbon = ribbon
End Sub
Sub GetVisible(control As IRibbonControl, ByRef returnedVal)
returnedVal = True
End Sub
Sub HideControl(control As IRibbonControl, ByRef returnedVal)
returnedVal = False
End Sub
Hi Greg,
Sorry, but posting XML to the blog is pretty tricky.
This is the second instance of this I've seen in the past 24 hours, and I'd agree that it is a bug. It works fine so long as you don't have startFromScratch set to true, and I'm guessing that MS doesn't just hide the tabs when this setting is on.
The workaround would be to create your own custom tabs using the MSO groups so it looks the same.
I'm going to bug this with MS as well. 🙂
Ken
FYI, Robert also has a page on his site about the MsoTabs as well: http://www.msofficegurus.com/gArticle.asp?IDArticle=45
Thanks, Ken. Of course my main reason for starting from scratch was to be sure I hid all tabs, not just the standard ones. I'll work around it. Thanks again.