Adding RibbonX code to an Office OpenXML file using VBA

My previous post went a bit unnoticed, but I bet this one might interest some of the Office developers…

In that post, I showed how to access and modify existing parts of an Office OpenXML package. This opens up the path for us to add ribbon customisation code to an Office file. For this to happen, a couple of modifications were needed to the code in the class module I showed earlier. Fellow Excel MVP Ken Puls was kind enough to make some modifications to the class module, which I refined a little. The results are on this page

Enjoy!
Regards,
Jan Karel Pieterse

Posted in Uncategorized

11 thoughts on “Adding RibbonX code to an Office OpenXML file using VBA

  1. This technique can easily be used to give us a fully-flexible, fully-customizable, run-time-modifiable Ribbon. All we need to do is create an empty xlax, inject the RibbonX we need using this technique, then open it. If we want to change the RibbonX, we close the xlax and repeat. For the RibbonX callbacks, we can include a file name in the callback proc, to call into the code that’s rebuilding the RibbonX.

  2. I may be being dense. Is there an XLAX file type that’s distinct from XLSX and XLAM file types? That is, is there a file type specifically for add-ins without VBA modules?

    My concern is security. Using an XLAM or XLSM file to create other files on the fly that could in turn indirectly call arbitrary procedures would introduce a new attack vector for malware. I wouldn’t want any code I hadn’t reviewed creating or modifying files in trusted locations. However, if the ad hoc UI files were created in untrusted locations, there could be security snags when loading those files. I’m assuming that files created by code can’t be certified automatically. Even if they could, I doubt that would be a good thing.

  3. After inserting the RibbonX code and loading it, it shows the Ribbon Customisations. The customisation XML must ensure the callbacks point to your “main” addin, which contains all code.

  4. Oki,I can see that function in this scenario, a carrier of xml instructions. But in general, what would be the purpose of an xlax file and the file format?

  5. @Harald: Theoretically, if we were just trying to move built-in Microsoft tabs & controls around to make the UI more efficient for our use, we wouldn’t need a macro enabled file format as no VBA would be needed. (Since the XML doesn’t count as a macro.) As soon as we start adding our own routines to the add-in though, we’d be forced to use an xlam format to save the code.

    @Stephen/Jan Karel: Was that meant to be XLAM, or did you really mean XLAX? I can’t see any option, either through the UI or code that supports an XLAX file format. My original vision was to do exactly what you said, but via an XLAM file, with any procedures “calling home” to a central handler. This should allow the creation of a table driven UI for all controls. It suffers the unload/unzip/modify/re-zip/re-open round trip time, but at least we can actually make it work.

    @fzz: I’m not quite sure how this makes an additional security concern. We can already create other file formats (non Excel) on the fly and run them. With regards to this specific portion, we’re actually looking at creating XML for the customUI which runs, trusted location or untrusted. The VBA is a different matter, but XML is not seen as potentially vicious, I guess.

  6. Ken: My suggestion was from memory – using an xlax format so it wasn’t sensitive to the active workbook, but also didn’t have any macro security prompt issues. That was during the original beta cycle when I was playing around with the Ribbon, so maybe it was dropped somewhere along the way.

  7. Thanks Stephen! I can see where it would have a use, although I suspect that most people who actually bit the bullet and customized their ribbon would actually want to expand to include their own procedures anyway. Maybe that’s why it got dropped.

  8. Ah, And there I was, just echoing Stephen’s remarks. From memory as well.
    OK, to recap: Using the code I demonstrated, you can have your addin create it’s own accompanying xlam with just ribbonX code inside it. The ribbonx code in the satelite xlam calls VBA code in the parent addin.


Posting code? Use <pre> tags for VBA and <code> tags for inline.

Leave a Reply

Your email address will not be published.