locked
DocumentOpen and WindowActivate events do not fire on Word 2010 RRS feed

  • Question

  • Hi,

    I have a Word Add-in which subscribes to both the DocumentOpen and WindowActivate events. I have a machine where both Office 2007 and Office 2010 are installed.

    On this machine, when I open a saved document by double clicking on it, the DocumentOpen and WindowActivate events are not fired. However, when I start up word first and open the saved document through the File menu, all events fire as expected.

    This behavior does not occur on Office 2007 on the same machine. Any pointers on what might be causing this problem would be very helpful


    Olorin
    Wednesday, April 14, 2010 4:48 AM

Answers

  • In Word 2010 the word startup behavior is changed, VSTO runtime waits for Word to be ready before firing the ThisAddIn_Startup event. And In this scenario by that time the DocumentOpen and WindowActivate events are already fired.

    You may have subscribed to DocumentOpen event in StartUp event, as in this scenario the StartUp event is fired after the Document Open event the addin subsribes to Document Open event after it is already fired.

    You can workaround this. As follows

    1. Declare a private variable called initialized (bool) in ThisAddIn.cs

     public partial class ThisAddIn  {    bool initialized = false;    private void ThisAddIn_Startup(object sender, System.EventArgs e)

    2. Create a new function in ThisAddIn.cs called InitializeCustom and subscribe to DocumentOpen event in this event

     private void InitializeCustom()    {      initialized = true;      Globals.ThisAddIn.Application.DocumentOpen += new Word.ApplicationEvents4_DocumentOpenEventHandler(Application_DocumentOpen);      Globals.ThisAddIn.Application.WindowActivate += new Word.ApplicationEvents4_WindowActivateEventHandler(Application_WindowActivate);    }

    3. Call InitializeCustom from Initialize method in ThisAddIn.Desiger.cs

     [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Tools.Office.ProgrammingModel.dll", "10.0.0.0")]    [global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]    protected override void Initialize() {      base.Initialize();      ....      ......      this.InitializeCustom();    }

    The above will result into subscribing to the events just when the AddIn is initialized. What we need to take care is that ThisAddIn.Designer.cs file can be regenerated anytime by VS and the InitialCustom() call will be removed from Initialize() method in this case.

    To prevent that resulting into a bug you can add the following Debug.Assert into ThisAddIn_Startup to check if InitializeCustom is called before the StartUp event

    private void ThisAddIn_Startup(object sender, System.EventArgs e)    {      // Make sure InitializeCustom has executed - i.e. it might not run      // if the .Designer.cs file is somehow regenerated. So, below check      // is a safety net      Debug.Assert(initialized);          }

    Navneet
    • Marked as answer by Bessie Zhao Monday, April 19, 2010 3:23 AM
    Thursday, April 15, 2010 11:05 PM

All replies

  • In Word 2010 the word startup behavior is changed, VSTO runtime waits for Word to be ready before firing the ThisAddIn_Startup event. And In this scenario by that time the DocumentOpen and WindowActivate events are already fired.

    You may have subscribed to DocumentOpen event in StartUp event, as in this scenario the StartUp event is fired after the Document Open event the addin subsribes to Document Open event after it is already fired.

    You can workaround this. As follows

    1. Declare a private variable called initialized (bool) in ThisAddIn.cs

     public partial class ThisAddIn  {    bool initialized = false;    private void ThisAddIn_Startup(object sender, System.EventArgs e)

    2. Create a new function in ThisAddIn.cs called InitializeCustom and subscribe to DocumentOpen event in this event

     private void InitializeCustom()    {      initialized = true;      Globals.ThisAddIn.Application.DocumentOpen += new Word.ApplicationEvents4_DocumentOpenEventHandler(Application_DocumentOpen);      Globals.ThisAddIn.Application.WindowActivate += new Word.ApplicationEvents4_WindowActivateEventHandler(Application_WindowActivate);    }

    3. Call InitializeCustom from Initialize method in ThisAddIn.Desiger.cs

     [global::System.Diagnostics.DebuggerNonUserCodeAttribute()]    [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Tools.Office.ProgrammingModel.dll", "10.0.0.0")]    [global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]    protected override void Initialize() {      base.Initialize();      ....      ......      this.InitializeCustom();    }

    The above will result into subscribing to the events just when the AddIn is initialized. What we need to take care is that ThisAddIn.Designer.cs file can be regenerated anytime by VS and the InitialCustom() call will be removed from Initialize() method in this case.

    To prevent that resulting into a bug you can add the following Debug.Assert into ThisAddIn_Startup to check if InitializeCustom is called before the StartUp event

    private void ThisAddIn_Startup(object sender, System.EventArgs e)    {      // Make sure InitializeCustom has executed - i.e. it might not run      // if the .Designer.cs file is somehow regenerated. So, below check      // is a safety net      Debug.Assert(initialized);          }

    Navneet
    • Marked as answer by Bessie Zhao Monday, April 19, 2010 3:23 AM
    Thursday, April 15, 2010 11:05 PM
  • Thanks Navneet!

    It worked for me.

    Saturday, October 22, 2011 9:08 AM
  • How about for Powerpoint?
    Tuesday, May 24, 2016 7:22 AM