locked
Ribbon invalidation in SDI excel 2013 callback affect wrong window RRS feed

  • Question

  • Hi,

    I'm having an issue where ribbon invalidation affects a non active window. I've a addin excel file providing a ribbon interface globally throughout excel.

    Some buttons need to enable/disable based on the state of the active file. To handle this i invalidate the ribbon on window changes.

    If I switch between Excel 2013 (or Excel 2016 preview) windows by clicking by mouse on the titlebar, i get one call to my getEnabled() callback and the ribbon in the newly activated workbook update properly.

    If I switch instead by clicking somewhere inside the excel sheet of the inactive worksheet I get two calls to getEnable(), the first one affecting the OLD workbook/window the second one the new one.

    In both callback's the IRibbonControl.Context refer to the newly activated workbook, and Application.ActiveWindow does the same.

    There don't seem to be a way to differentiate between for which window the callback was made for, and the callback probably should not have been made in the first place since it's the new window which have the ribbon that now is invalidated.

    I'm suspecting the bug lies in that the ribbon code calls the callbacks with context set to ActiveWindow, instead of the window that the ribbon control actually lies on.

    Any thoughts on if there is some workaround?


    • Edited by Joakim Plate Thursday, July 9, 2015 11:41 AM Update for Excel 2016 preview
    Thursday, September 12, 2013 1:42 PM

All replies

  • What do you mean "affects a non active window"?

    Could you share some code here?

    Tuesday, September 17, 2013 3:14 AM
  • Hi.

    Took some time to get back on this :). I've uploaded a sample here:

    https://drive.google.com/file/d/0B_OgiNVBtoZ3eUItN25BVWc2QnM/edit?usp=sharing

    The sample contains code that will (on press of commandbutton on sheet):

    1. Add two new workbooks
    2. Switch itself to an addon (so ribbon is globally in effect)
    3. Register for window change notification

    The callback for OnWindowChange invalidate the complete ribbon. The ribbon has a customUI with a single extra tab ("Custom Tab") with a button who's label is updated by a VBA callback as follows:

    Sub getLabel(control As IRibbonControl, ByRef vValue As Variant)
        vValue = control.Context.Parent.Name
    End Sub

    Thus the label of the button should represent the name of the window that the getLabel callback is affecting (context is the window in this case).

    1. Start the example by pressing the button.
    2. Switch both windows ribbon to the "Custom Tab" so the button is visible and you can see them both.

    The name of the button should be "Book1" on the first workbook, "Book2" on the second.

    Activate the non active window by pressing on any cell in the sheet

    -> Both windows button names will invalidly switch to the new window name 

    Activate the non active window by pressing somewhere on the ribbon

    -> Only the new window will update to the correct name

    Hope this shows helps in debugging the issue.


    Thursday, February 13, 2014 2:19 PM
  • I seem to get reproducable segmentation faults with excel on close with that simple example too. Might be worth investigation :)

    Excel: 15.0.4535.1507 MSO: 15.0.4551.1007

    Thursday, February 13, 2014 2:29 PM
  • What a mess. Great work, MS.
    Friday, February 14, 2014 1:47 PM
  • Hi Joakim,

    I donwloaded your file. Tested it using Excel 2010

    I failed to reproduce the following:

    >If I switch instead by clicking somewhere inside the excel sheet of the inactive worksheet I get two calls to getEnable(), the first one affecting the OLD workbook/window the second one the new one.

    I was switching between windows in different fashions:

    - by cliking the corresponding shortcut on the Taskbar

    - "by clicking somewhere inside the excel sheet"

    - "by clicking by mouse on the titlebar"

    - by Ctrl + Tab

    - by choosing the window using a ribbon(Tab View --> Switch Windows)

    The result was the same - one call of getLabel.

    Then I made a test using Excel 2013. This time getLabel was called two times indeed.

    >Any thoughts on if there is some workaround?

    Try this one:

    Sub getLabel(control As IRibbonControl, ByRef vValue As Variant)
        vValue = control.Context.Parent.Name
        DoEvents
    End Sub

    Using DoEvents prevents getLable from calling two times in my Excel.

    Is it of some help to you?

    Sergiy Vakshul



    • Proposed as answer by Sergiy_Vakshul Sunday, February 16, 2014 12:23 PM
    • Unproposed as answer by Joakim Plate Thursday, February 20, 2014 3:20 PM
    • Edited by Sergiy_Vakshul Thursday, February 20, 2014 3:25 PM
    Sunday, February 16, 2014 12:23 PM
  • Hi,

    I tried it, but it didn't help with a more complete setup with multiple callbacks. It also made the menu redrawing unusably slow (have about 500 callbacks to get data).

    /Joakim

    Thursday, February 20, 2014 3:19 PM
  • So,

    what are you going to do? Have you decided?

    If you find another workaround, please, share it with me.

    Sergiy Vakshul

    Thursday, February 20, 2014 10:59 PM
  • For now i've just given up.
    Saturday, May 10, 2014 4:08 PM
  • An update on this. Issue remains in Excel 2016 preview. I wonder if we can get this elavated to be solved before the new office release goes out.
    Thursday, July 9, 2015 11:39 AM
  • seems not. Issue remain in 2016 RTM.
    Thursday, June 30, 2016 10:59 AM
  • This really is a mess, as my company's add-in heavily customizes the ribbon and this bug is noticeably affecting the performance of Excel 2016 as it's double-refreshing the two front-most Excel windows every time we invalidate the active window.

    Microsoft really needs to address this ASAP...

    Monday, July 2, 2018 9:12 PM