Comments on: Adding RibbonX code to an Office OpenXML file using VBA

By: Jan Karel Pieterse

Jan Karel Pieterse — Fri, 22 May 2009 18:30:00 +0000

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.

By: Ken Puls

Ken Puls — Thu, 21 May 2009 15:42:00 +0000

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.

By: Stephen Bullen

Stephen Bullen — Thu, 21 May 2009 09:12:00 +0000

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.

By: Ken Puls

Ken Puls — Thu, 21 May 2009 05:02:00 +0000

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

By: Harald Staff

Harald Staff — Wed, 20 May 2009 19:33:00 +0000

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?

By: Jan Karel Pieterse

Jan Karel Pieterse — Wed, 20 May 2009 18:43:00 +0000

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.

By: Harald Staff

Harald Staff — Wed, 20 May 2009 17:53:00 +0000

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

By: Jan Karel Pieterse

Jan Karel Pieterse — Tue, 19 May 2009 19:11:00 +0000

Stephen: Excellent suggestion!

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

By: fzz

fzz — Tue, 19 May 2009 18:50:00 +0000

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.

By: Ron de Bruin

Ron de Bruin — Tue, 19 May 2009 14:58:00 +0000

Hi Stephen

Good suggestion
Yes this will work good.