none
Load CustomUI selectively at Word startup RRS feed

  • Question

  • Hello

    We have developed an application, lets call it "Bear", that automatically loads Word 2003 with the (.rtf) document the user requests.
    "Bear" disables certain commands from the Word commandbar through the use of COM-automation, for instance the user can't save the file through the built-in "Save" or "Save As" function.

    As we are now in the process of migrating to Word 2010, we have to find a way of disabling the appropriate Ribbon elements. As an example, lets say we want to disable the entire Backstage tab.

    I've been experimenting and have created a CustomUI.xml witch disables all the elements in Backstage, so that works.

    However the problem is that Word should be 100% original when used outside of "Bear". So having the CustomUI add-in loaded automatically at _every_ startup is not an option. Embedding CustomUI in the documents is not an option either as they are in rich text format.

    I can imagine a couple of solutions to this problem, but I'm not sure which is possible:
    -Is it possible to load a Word-addin selectively at startup, say through a command line switch or in some programmatic fashion?
    -What about disabling backstage elements entirely using COM calls from "Bear"?
    -Can a COM add-in read some information outside of Word, say some temporary file "Bear" has created in which case backstage is disabled?

    Friday, August 12, 2011 1:18 PM

Answers

  • Yes, the add-in must be a shared add-in (or a Word template you load as an addin). The problem with a VSTO add-in is that it's "wrapped up" and managed by the VSTO loader/runtime so you can't get at it directly.

    The callback of a Ribbon button can call a procedure that was formerly (or still is) used by a CommandBar button. For example

    Public Sub button_OnClick(control as IRibbonControl)
      MyToolbarButtonProcedure
    End Sub


    Cindy Meister, VSTO/Word MVP
    Monday, August 15, 2011 2:34 PM
    Moderator

All replies

  • It would help to know whether this is a VSTO add-in or a "Shared add-in"...

    Add-ins can be installed to "load on demand". If we're talking a Shared Add-in, then you can load/unload it via Word's Application.COMAddins object.

    COM calls can't affect the Ribbon. Only the process which loads the Ribbon (the add-in) can change the Ribbon

    Backstage has OnShow and OnHide callbacks that trigger when the user clicks "File". You can use this to Invalidate the Ribbon. The callbacks for getEnabled or getVisible for various controls can certainly look-up information from outside Word (read an XML file, the Registry, an INI file - whatever you like) and use that to evaluate their state before the Backstage is presented to the user.


    Cindy Meister, VSTO/Word MVP
    Friday, August 12, 2011 4:04 PM
    Moderator
  • Thank you very much for your reply.

    I'm going to try calling COMAddin.connect from "Bear" to get the add-in to load when needed. Does the add-in have to be a shared add-in for this to work (Not VSTO)?

    Another thing I'm wondering; is it possible to embed functionality from old-style custom commandbar in the Ribbon UI? Eg. trigger events on buttons now residing in the Add-On tab from new Ribbon-style buttons.


    Monday, August 15, 2011 9:42 AM
  • Yes, the add-in must be a shared add-in (or a Word template you load as an addin). The problem with a VSTO add-in is that it's "wrapped up" and managed by the VSTO loader/runtime so you can't get at it directly.

    The callback of a Ribbon button can call a procedure that was formerly (or still is) used by a CommandBar button. For example

    Public Sub button_OnClick(control as IRibbonControl)
      MyToolbarButtonProcedure
    End Sub


    Cindy Meister, VSTO/Word MVP
    Monday, August 15, 2011 2:34 PM
    Moderator