[Word / WPF] Custom Task Panel Contents disappear when document closed

[jeffkayser]

The contents of Custom Task Panes (CTP) containing WPF (UserControl) content disappear when closing a modified Word document. The add-in itself seems to remain loaded, and the space reserved for the CTP remains, but its contents are no longer available/updated.

This can be reproduced using the WordAddIn1 example that comes with VSTOContrib.

Steps to reproduce using the above add-in:

1. Launch Word with test add-in containing a CTP loaded
2. Open new, blank document
3. Enter some text
4. Select the text to have the add-in populate the CTP with content
   
5. Click Cancel when the "Do you want to save changes made to Document1"? dialog appears
   
6. The CTP should have been blanked out during the previous step
   
7. Note that the CTP content isn't updated/redrawn anymore [0]

[0] Clicking Show Panel in the add-in's Ribbon seems to indicate the CTP has been unloaded, as clicking it gives a NullReferenceException with myAddinTaskPane being null in the PanelShown property setter in DocumentViewModel.cs

Any ideas on how to prevent this from happening? Despite canceling the closing of the document or exiting of Word, it seems as though the CTP is being unloaded. The add-in only behaves normally after closing and relaunching Word.

Please let me know if additional information is required.

Thanks!

[jeffkayser]

Forgot to note that I have seen this on Office 2010 (Windows 7, Windows Server 2008 R2) and Office 2013 (Windows 8.1)

[aafvstam]

The scenario in general, Close Document by pressing X top right - instead of save, saveas click Cancel to return to Word. You find that if you had a Custom Ribbon Tab it will be removed as well. From what I see the DocumentClose event is unloading the DocumentClose event itself plus unloads the document (document == null). After returning to Word you lost the registered View. A bug if you ask me...

[aafvstam]

In order to solve this you need to add the ThisAddIn_DocumentBeforeClose eventhandler to your add-in. As this is an application event you cannot add this to the DocumentWrapper class.

So what you do is to start the eventhandler when your add-in is loaded you add to your ThisAddin_Startup method:

((ApplicationEvents4_Event)Globals.ThisAddIn.Application).DocumentBeforeClose += ThisAddIn_DocumentBeforeClose;

And to shut down the eventhandler when your add-in is unloaded to your ThisAddIn_Shutdown method:

((ApplicationEvents4_Event)Globals.ThisAddIn.Application).DocumentBeforeClose -= Application_DocumentBeforeClose;

And the real work is done in the eventhandler itself:

   void ThisAddIn_DocumentBeforeClose(Document Doc, ref bool Cancel)
        {
            Debug.Print("Handle DocumentBeforeClose");

            if (Doc.Saved == true) return;

            Debug.Print("Document needs to be saved, otherwise uncontrolled Save routine from Word kicks in");

            WdAlertLevel alert = Doc.Application.DisplayAlerts;
            Doc.Application.DisplayAlerts = WdAlertLevel.wdAlertsNone;

            DialogResult result = MessageBox.Show(string.Format("Do you want to save the changes to {0}?", Doc.Name), Strings.ApplicationName, MessageBoxButtons.YesNoCancel, MessageBoxIcon.Exclamation);

            if (result == DialogResult.Yes)
            {
                Debug.Print("DocumentBeforeClose - Save document");

                try
                {
                    Doc.Save();

                    // Validate and check if the document is actually saved otherwise revert back and cancel the close event.
                    if (Doc.Saved == false)
                    {
                        Debug.Print("DocumentBeforeClose - Save document failed");
                        Cancel = true;
                    }
                }
                catch (System.Exception ex)
                {
                    Debug.Print("Save Document {0} failed: {1}, Abort Close", Doc.Name, ex.Message);
                    Cancel = true;
                }
            }
            else if (result == DialogResult.No)
            {
                Debug.Print("DocumentBeforeClose - Close without saving");
                Doc.Saved = true; // Close without saving
            }
            else
            {
                Debug.Print("DocumentBeforeClose - Close cancelled");
                Cancel = true; // Abort, close canceled
            }
            Doc.Application.DisplayAlerts = alert;
        }

What this does is before going into the DocumentClose event that kills the document from the ViewModel and tests to see if the document is saved or not. If already saved the DocumentClose procedure can continue but if not the user gets the same Yes, No, Cancel question to save the document. This allows you to abort the DocumentClose and avoid the situation you entered previously where the Save dialog is shown while the document was already removed from its ViewModel.

Let me know if this worked for you.

[harouny]

Hey, I want to report having the same issue.
Scenario:

• Open a word document while add-in is installed.
• These functions will be called in IRibbonViewModel:
  • IRibbonViewModel constructor
  • Initialised
  • RegisterTaskPanes
• Make any change in the document.
• Click Close button, (the x icon) in the top right of Word.
  Note: Because of the issue, we are hiding the task pane here by handling Document.DocumentBeforeClose event.
• These functions will be called in IRibbonViewModel:
  • Cleanup
• Click Cancel on word (Save, Don't Save, Cancel) dialog.
• These functions will be called in IRibbonViewModel:
  • IRibbonViewModel constructor (means another object is created)
  • Initialised

Note: that RegisterTaskPanes is not called and the task pane will fail to be visible again.
The only way to get the task pane loaded correctly now is to switch the focus to another application then switch back to word (or minimize the maximize word). This will somehow trigger RegisterTaskPanes again and the task pane should be loaded correctly.

[aafvstam]

The reason that RegisterTaskPanes is not called is because the document has already been unloaded by the Word Close routine.

Instead of hiding the task pane in the DocumentBeforeClose you should handle the Saved state of the document in your own DocumentBeforeClose before Word takes over and revert back to your document if you canceled in the DocumentBeforeClose routine.

I provided the example in my post above. By doing so Word won't kick in closing of the document and VSTOContrib does not reach closing of the document if the user decides to Cancel in DocumentBeforeClose.

Maarten

[harouny]

Hi Maarrten, we decided that handling DocumentBeforeClose and providing our own custom UI and override Word built-in dialog is dangerous to be a valid solution in our case. Imagine if a new version of Word decided to include a new feature in that dialog or change the way its presented. Also we will have to find a way to exactly match the UI including localization to different languages.

[aafvstam]

I agree with what you say, there is however no other option to know if a user returned from a canceled Save sequence. I also discussed this a couple of years ago with one of the Microsoft development teams that there is missing a Document->After<-Close event. This would be the right place to do the cleanup, unloading and other finalizing work that is now done before the Save dialog kicks in.

I found that changing focus will only partly solve the issue resulting in Key not Found exceptions in the dictionaries and other unexpected behavior (you can see exceptions if you enabled the option "Show add-in user interface errors" in Word Options under Advanced - General, there are people who have this enabled). Changing focus indeed reloads the missing DocumentView but I wasn't able to properly get rid of the unexpected exceptions.

It is not an easy issue to get out of the way apparently.