none
Integration of multiple add-ins RRS feed

  • Question

  • I am developing a VSTO word addin which needs to load other addin ribbon UI controls into its main ribbon.

    Essentially I want to provide to the developers of a few existing addins the ability to integrate (provide their functionality under my Office Ribbon Tab) with minimal dev effort.

    I know I could use IDQs to achieve this, but I need the ability to reposition controls programmatically and control access to functionality for licensing and security.  

    What is the best way to do this? Any ideas?

    Friday, February 15, 2013 4:26 PM

Answers

  • you will have to do this in coordination with other add-ins' authors - they should for example provide files with well known names that your main add-in will load and parse and forward calls from buttons to them (i.e. through ribbon automation services interface). Ribbon by design explicitly forbids manipulation of other addin's buttons.
    Friday, February 15, 2013 4:57 PM
  • sure you can use reflection, this is exactly what vsto runtime is using itself to call your code and discover what capabilities your add-in exposes.
    Wednesday, February 20, 2013 5:00 AM
  • should work, but i would not go the route of createribbonextensibility override but standard way as your child add-ins.
    Wednesday, February 20, 2013 7:41 PM
  • because as i recall createribbonextensibility override did not work with ribbon customization for launching mail compose/view window when outlook was not running. And standard means 'normal' way of overriding RequestService
    Thursday, February 21, 2013 10:53 AM

All replies

  • you will have to do this in coordination with other add-ins' authors - they should for example provide files with well known names that your main add-in will load and parse and forward calls from buttons to them (i.e. through ribbon automation services interface). Ribbon by design explicitly forbids manipulation of other addin's buttons.
    Friday, February 15, 2013 4:57 PM
  • That's right. I would like to provide some interfaces so that my add-in can load the various ribbon elements of the interface implementer. I would like to make it as easy as possible for the developers of the existing add-ins to implement the interface and expose their buttons and functionality (for my add-in to use). My vision is to create a plugin architecture for a number of existing add-ins so that their functionality can be provided as one single product in a controlled way (ie. show\hide relevant ribbon controls depending on user entitlements).

    Sunday, February 17, 2013 9:18 PM
  • i do not see any question in your response. Anyway there is not much in add-in architecture by itself to help you in your goal, you cannot depend on add-in load order so you cannot be sure that your add-in loads last. As i said - i would go the way of custom ribbon file format for integration then expose all buttons by main add-in and forward calls from controls to other add-ins via automation services exposed by other add-ins.
    Monday, February 18, 2013 5:04 AM
  • Hi Damian / Leonardo

    <<Anyway there is not much in add-in architecture by itself to help you in your goal, you cannot depend on add-in load order so you cannot be sure that your add-in loads last.>>

    This can be accomplished by having only the one (main) add-in load automatically. Everything else would have to be set to load on-demand. Then the other add-ins could be loaded by the main one as required (set the Connect property of the ComAddin object to True) and in the desired order.


    Cindy Meister, VSTO/Word MVP, my blog

    Monday, February 18, 2013 11:13 AM
    Moderator
  • Hi Cindy :-)

    problem with .Connect=true would not solve the issue with 'master' add-in orchestrating 'child' add-ins' buttons. And AFAIR there are problems with .Connect if plugin is installed for all users and executed in non-admin context.

    Monday, February 18, 2013 11:41 AM
  • Hi Damian

    <<And AFAIR there are problems with .Connect if plugin is installed for all users >>

    Indeed, the ComAddins collection only "sees" Addins in the HKCU, not in the HKLM. As far as loading the Ribbon customizations in any particular order, though, I think that's the only possibility.

    Otherwise, I can only imagine that the "master" somehow is provided access to the Ribbon XML of all the "child" add-ins, incorporates that into its own Ribbon XML and maps the controls to "stubs" that call "visible" code in the other add-ins.

    So that would mean the "child" add-ins would need to provide all the necessary information in some kind of "config" file (Ribbon XML, method names, etc.). And, of course, those add-ins should then not load any Ribbon customization.


    Cindy Meister, VSTO/Word MVP, my blog

    Monday, February 18, 2013 3:52 PM
    Moderator
  • Hi Cindy / Damian,

    Thanks for taking the time to help.

    I was thinking more along the lines of what Cindy described last. I do not wish to load every addin (ribbon).

    Ideally, the addins would implement an interface to expose their ribbon/ribbon controls. I then reference to their assembly and merge/load the controls onto my own ribbon using a mapping algorithm.

    Any smart ideas on how to do this – keeping in mind that I want to minimise dev work on the existing addins?

    How about using reflection to discover and use the third party addin ribbons and the functionality provided, without changing the third party addins code at all? Is this even a possibility?

    Tuesday, February 19, 2013 3:11 PM
  • sure you can use reflection, this is exactly what vsto runtime is using itself to call your code and discover what capabilities your add-in exposes.
    Wednesday, February 20, 2013 5:00 AM
  • Can you see any issues with the approach described below?

    Let’s assume that all addins use Ribbon Xml – no Ribbon Designer.

    1. Create a word addin
    2. Create a class which implements IRibbonExtensibility (for argument sake let’s call it MainRibbon)
    3. MainRibbon is provided with an assembly folder path (which contains all addins and dependencies - ChildAddins)
    4. MainRibbon will scan the folder assemblies to find all implementations of IRibbonExtensibility
    5. For each implementation, it will create an instance of it, give it an id and retrieve the ribbon xml using GetCustomUI()
    6. It will then merge the xml from all the various ribbon instances into one ribbon xml. This process will need to be specified in detail and should probably be customisable using config map files. All callbacks will need to be rerouted to the right ribbon instance and method
    7. In main add in override CreateRibbonExtensibilityObject() and return an instance of class MainRibbon
    8. When the MainRibbon loads (ie. load callback is executed) all the children load callbacks will be called passing through the same IRibbonUI of the mainribbon callback method

    Wednesday, February 20, 2013 4:50 PM
  • should work, but i would not go the route of createribbonextensibility override but standard way as your child add-ins.
    Wednesday, February 20, 2013 7:41 PM
  • Hi Damian,

    Thanks for your reply.

    What do you mean by the standard way? And why do you prefer this approach?


    • Edited by Lenny S Thursday, February 21, 2013 10:18 AM grammer error
    Thursday, February 21, 2013 10:18 AM
  • because as i recall createribbonextensibility override did not work with ribbon customization for launching mail compose/view window when outlook was not running. And standard means 'normal' way of overriding RequestService
    Thursday, February 21, 2013 10:53 AM