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. Hi Stephen

   Good suggestion
   Yes this will work good.

3. 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.

4. Stephen: Excellent suggestion!

   fzz: an xlax is an Excel 2007 addin without VBA (as opposed to an xlam, which is an addin with code).

5. Apologies for my ignorance here. An addin without VBA does what?

6. 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.

7. 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?

8. @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.

9. 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.

10. 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.

11. 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.