IRibbonUI.InvalidateControl and backstage controls with qualified ids RRS feed

  • Question

  • Hi

    I am working on a VSTO Word add-in  (Office 2013 developer tools for VS2012 preview 2, C#, .Net 4.5) with a ribbon customization.

    I am using qualified control IDs to avoid overlapping IDs in an enterprise environment where multiple add-ins may be installed. I have successfully registered the namespace using the addin progid (fully qualified addin class name). I thus have no problem getting callbacks to get control state (label, visible, enabled etc.) and handle actions (onaction).

    However I am unable to invalidate controls using IRibbonUI.InvalidateControl when controls are identified by a qualified id. According to Customizing the 2007 Office Fluent Ribbon for Developers InvalidateControl must be called with the ID value part of the qualified Id, but this does not seem to work. I have also tried calling with the qualified ID to no effect. Calling IRibbonUI.Invalidate works fine, but seems excessive/wastefull for simple updates to visible/enabled state. IRibbonUI.InvalidateControl works fine when only using unqualified IDs.

    I am currently considering this maybe a bug, but would like to know if anyonehave successful used InvalidateControl using qualified IDs?

    Ribbon UI example

    <?xml version="1.0" encoding="UTF-8"?>
    <customUI onLoad="CustomUILoad" loadImage="CustomUILoadImage" xmlns="" xmlns:nnit="NNIT.Office.Word.QualityDocumentAddIn">
      <ribbon startFromScratch="false">
        <tab idQ="nnit:TabQualityDocumentNew" getLabel="GetCustomUIControlLabel" getTitle="GetCustomUIControlTitle" getEnabled="GetCustomUIControlEnabled" getVisible="GetCustomUIControlVisible">


    • Edited by Kasper W Tuesday, February 12, 2013 4:50 PM Title updated
    Tuesday, February 12, 2013 11:59 AM


All replies

  • Further examination showed that the problem with invalidating qualified controls only applies to backstage controls. Ribbon controls with qualified IDs are correctly invalidated. The problem is thus most likely a bug in the InvalidateControl method.
    • Marked as answer by Kasper W Tuesday, February 12, 2013 4:53 PM
    • Unmarked as answer by Kasper W Tuesday, February 12, 2013 5:28 PM
    • Edited by Kasper W Tuesday, February 12, 2013 5:28 PM fixed spelling.
    Tuesday, February 12, 2013 4:52 PM
  • Hi Kasper,

    Thanks for posting in the MSDN Forum.
    I will involve some experts into your thread to see whether they can help you out. There might be some time delay, appreciate for your patience.

    Have a good day,


    Tom Xu [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, February 13, 2013 12:15 AM
  • Hey Kasper,

    I do get the behavior you mention, but I'm not seeing a way to accomplish this in the backstage.  I can submit this feedback to the product group so they are aware of the behavior.  If you do need to find a way of accomplishing something similar, you can open a paid support case to investigate any alternatives.;en-us;offerprophone 


    Thursday, February 21, 2013 8:25 PM
  • Hi Brandon

    Thanks, I would appreciate you submitting the feedback to the product group for possible fixing. I have my self not found any way of reporting potential bugs in preview 2 of the office 2013 developer tools for VS2012. I will use the method for fully invalidating the custom ui as a workaround.

    I would also appreciate if you could pass on the following issue, which I also consider to be a potential bug:

    When using unqualified ids, the IRibbonControl instance passed in control callbacks have the Id property set to the control id, however, when using qualified id's, the Id property is empty. It is thus not possible to identify the control which is the source of the callback. I prefer to use a common callback method for the same control property e.g. a single GetLabel callback method and then returning the correct label value depending on the control.Id property.
    I am currently using the Tag property as a work around for identifying the callback source control by setting the Tag value to the same value as the qualified id and then identifying the control using the Tag property of the IRibbonControl instance passed to the callback then the ID property is empty.
    This workaround is fine as long as the Tag property is not needed for other purposes. Another workaround would be to have separate GetLabel callback methods for each control, but this leads to excessive code maintenance.

    Thank you for your help.

    Friday, February 22, 2013 10:10 AM
  • Hi Kasper,

    We are closing the thread since the issue is reported and cannot proceed in forum.

    Thanks for your feedback!

    Best regards,

    Min Zhu
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, March 11, 2013 2:26 AM