Automatic Loading of ExcelRibbon Derived ComAddins

Oct 2, 2013 at 6:43 PM
I would like to understand the background/reasons on the decision to automatically load ribbon comaddins, i.e. comaddins derived from ExcelRibbon . I had expected that this would have been an explicit action within the AutoOpen of the xll addin that I am writing as opposed to being a behavior of the Dnalibrary.

Any insights would be appreciated as well as suggestions for approaches to place the ExcelRibbon derived comaddin loading under my explicit control within my AutoOpen.

Oct 2, 2013 at 7:04 PM
Edited Oct 2, 2013 at 7:05 PM

There was no special decision around this - I've never before considered making the ribbon load explicit.
If you want to load the ribbon but not display it, you can do so with getVisible callbacks.

To make the ribbon load explicit, I can think of a few approaches:
  • Make a separate .xll add-in for the ribbon, and load it explicitly via XlCall.Excel(XlCall.xlfRegister, myRibbonAddInPath).
  • Don't inherit from ExcelRibbon, but instead inherit from ExcelComAddIn directly and implement IRibbonExtensibility yourself (you can just copy the ExcelRibbon code - there's not a lot). Then load via ExcelComAddInHelper.LoadComAddIn(myComAddIn) when you're ready.
Oct 2, 2013 at 7:25 PM

I had already considered the second approach, but wanted to proactively see if there was some constraints/reasons from someone with better insight.

Oct 3, 2013 at 5:01 PM
Hi Govert,

Turns out that implementing (copy and paste) ExcelRibbon has a few tentacles:
  • The GetCustomUI has a dependency on the Internal property DnaLibrary in ExcelComAddin.
  • If I implement (copy and paste) ExcelComAddIn it has a dependency on the interface IDTExtensibility2 whose accessibility is set to Internal.
  • If I implement (copy and paste) IDTExtensibility2 it has a dependency on the class ComAPI.gstrIDTExtensibility2 whose accessibility is set to Internal.
  • If I implement (copy and paste) ComAPI the has a dependency on the method ExcelComAddInHelper.LoadComAddIn requires a parameter of type ExcelComAddIn.
  • If I implement (copy and paste) ExcelComAddInHelper the number of dependencies within it grows substantially.
I considered a cast from MyExcelRibbontype toExcelRibbon` break the dependency chain here; but of course I am wondering what else maybe hidden from my limited view and knowledge. So, thought I would stop and ask if I am missing something obvious.

Oct 3, 2013 at 7:10 PM
HI Kirk,

I would suggest implementing your own version of GetCustomUI, whereby you provide the customUI xml string from code or extracted from your assembly's own resources instead of the Excel-DNA packed resources. With that change (and perhaps a similar change to the getImage, if you're using it), I think you should be able to make your own ExcelRibbon-like class that derives from Excel-DNA's ExcelComAddIn class.

Interfaces like IDTExtensibility2 are marked internal since they are really copies of interfaces found in the Office Primary Interop Assemblies. You can use those instead. But that does not some the fact that LoadComAddIn takes an ExcelComAddIn.

So I suggest you implement a class derived from ExcelComAddIn, and provide your own independent implementation of the IRibbonExtensibility.