locked
How to Determine whether BackStage is activated RRS feed

  • Question

  • Does anyone know of an easy way to determine this?  Application.OnTime fires while it is visible, and I would like to be able to determine that.

    An alternative would be to try to intercept the File ribbon command with a hook.  Is that possible?  If so, it then leaves the issue of knowing when the backstage has exited.  Messy.

    (I am drawing on top of the Excel window using WPf, and the Backstage seems to go in the same window, so I end up drawing on top of it as well!)

    Regards,

    Anthony


    Anthony
    Wednesday, November 16, 2011 8:43 AM

Answers

  • Does anyone know of an easy way to determine this? Application.OnTime fires while it is visible, and I would like to be able to determine that.

    Not sure what you mean by "Application.OnTime fires while it is visible". OnTime will fire on at the next schduled time, whether Backstage is activated or not. In the Ontime you could check if a child window of XLMAIN (of the relevant instance of course) exists with the classname "FullPageUIHost", I think normally the first window. If it exists it means Backstage is active.

    An alternative would be to try to intercept the File ribbon command with a hook. Is that possible? If so, it then leaves the issue of knowing when the backstage has exited. Messy.

    When Backstage is activated or closed OnShow and OnHide callbacks are triggered. There's an example of how to include the XML and VBA in a workbook here

    http://msdn.microsoft.com/en-us/library/ff634163.aspx

    It only includes OnShow but OnHide is similar. If trying the example be sure to "Validate" the xml, in particular watch out for this bit <!—The Backstage. Replace the long dash with a couple of hyphens.

    (I am drawing on top of the Excel window using WPf, and the Backstage seems to go in the same window, so I end up drawing on top of it as well!)

    No idea how you'd implement any of what I've suggested in your WPf

    Peter Thornton

    Wednesday, November 16, 2011 11:50 AM

All replies

  • Does anyone know of an easy way to determine this? Application.OnTime fires while it is visible, and I would like to be able to determine that.

    Not sure what you mean by "Application.OnTime fires while it is visible". OnTime will fire on at the next schduled time, whether Backstage is activated or not. In the Ontime you could check if a child window of XLMAIN (of the relevant instance of course) exists with the classname "FullPageUIHost", I think normally the first window. If it exists it means Backstage is active.

    An alternative would be to try to intercept the File ribbon command with a hook. Is that possible? If so, it then leaves the issue of knowing when the backstage has exited. Messy.

    When Backstage is activated or closed OnShow and OnHide callbacks are triggered. There's an example of how to include the XML and VBA in a workbook here

    http://msdn.microsoft.com/en-us/library/ff634163.aspx

    It only includes OnShow but OnHide is similar. If trying the example be sure to "Validate" the xml, in particular watch out for this bit <!—The Backstage. Replace the long dash with a couple of hyphens.

    (I am drawing on top of the Excel window using WPf, and the Backstage seems to go in the same window, so I end up drawing on top of it as well!)

    No idea how you'd implement any of what I've suggested in your WPf

    Peter Thornton

    Wednesday, November 16, 2011 11:50 AM
  • Thanks for the link, did not find it in my earlier searches.  I just catch the event and clear the drawing objects.

    One issue is that I now seem to need to copies of my ribbon description, on for XL2007 and a separate one for 2010.

    It would have been nice if the ribbon had a simple object modle just like just about everything else in the VBA and .Net world.

    (The timer is how I will handle user's scrolling and widening cells, for which there are no Excel events.  Not needed for backstage.)

    Anthony


    Anthony
    Thursday, November 17, 2011 4:13 AM
  • I don't think it'd cause any problems to include the UI14xml backstage stuff for use in 2007, but would need to double check.

    If using a timer anyway, to detect backstage why not something simple along the lines I suggested before in your other thread, eg

    BackStageOn = (FindWindowEx(xlApp.Hwnd, 0&, "FullpageUIHost", vbNullString)
     > 0)

    Perhaps with a more frequent timer method than is possible with OnTime

    I'm intrigued by your WPf. I have an approach to display and move a form (eg like a caption) say adjacent to the cursor cell. It works fine but for different needs it'd be nice to be able to trap keys as entered into the input bar, and display something like a prompt (can't trap input bar keys in VBA etc). Would that be possible with WPf?

    Peter Thornton

    Thursday, November 17, 2011 10:51 AM
  • Hello Peter,

    Thanks for that.  The OnShow/OnHide events actually do what I need (I just missed them, oops) so no need for a timer for that any more.  I generally try to avoid WinApi where possible, but should probably use it more.

    The Excel 2007 ribbon has a different namespace.  Backstage did not work in it for me, although I did not persevere.

    I don't think that WPF can do anything that WinApi cannot do, quite the opposite.  I use it because I want to display rich text in the task pane.  I am using VSTO, although ExcelDNA or Add ins Express might be better.

    I suspect that you would be deep into WinApi for trapping input bar keys, using subclassing.

    http://www.cpearson.com/excel/DetectScroll.htm and  http://www.informit.com/articles/article.aspx?p=366892&seqNum=3 are good places to start.

    I can also paint a transparent window near the active cell, using Pane.PointsToScreenPixelsX (Warning, the Window version is broken, see my earlier post.)

    Excel is missing events for column resize, window scroll etc. so I will use a timer for them.  Just note whether PointsToScreenPixelsX moves.  Could try to catch mouse events later, but never fool proof.

    Regards,

    Anthony


    Anthony

    Friday, November 18, 2011 12:42 AM
  • Thanks for that. As you say it would require some form of keyboard hook in something running asynchronously.

    Pane.PointsToScreenPixelsX (Warning, the Window version is broken, see my earlier post.)

    That all works fine for me, except I use Window rather than Pane. Can even to relate cursor "over" a cell without activating a cell, using RangeFromPoint. FWIW I use an API timer every 300ms

    Peter Thornton

    Friday, November 18, 2011 12:17 PM