Beware of AutoSave and DocumentBeforeSave

One of the cool things about Word is that it auto-saves your work so that if the machine dies or the app crashes you can get most of it back again. One of the other cool things about Word is that you can customise the built-in dialogs -- such as the Save As dialog -- to save yourself some development time and keeping the UI familiar to users.

Unfortunately these things don't work too well together right now. I have code similar to this in dotWord:

/// Called when the document is opened.

protected

void
ThisDocument_Open()

{

ThisApplication.DocumentBeforeSave += new Word.ApplicationEvents4_DocumentBeforeSaveEventHandler(BeforeSaveHandler);

}

private

void
BeforeSaveHandler(Word.Document Doc, ref bool SaveAsUI, ref bool Cancel)

{

// Get the default Save-As dialog to show to the user

Word.Dialog fileSaveAsDlg;

fileSaveAsDlg = thisApplication.Dialogs[Word.WdWordDialog.wdDialogFileSaveAs];

// Show the dialog. This will actually save the document if the

// user clicks the "Save" button.

    object missing = Type.Missing;

fileSaveAsDlg.Show(ref missing);

// Oooh, fun! It's like a choose-your-own-adventure

if
(MessageBox.Show("Do you want to crash [Yes] or show a silly dialog [No]?",

"Save bug"
, MessageBoxButtons.YesNo) == DialogResult.Yes)

Cancel = false;

else

Cancel = true;

}

In the real code I actually do some work to compute a decent file-name based on the blog title and today's date, but I omitted that from the sample since it uses reflection code that just gets in the way of the example.

Anyway, as the final MessgeBox suggests, you can either set the Cancel parameter to true (cancel the save operation) or false (continue the save operation). Neither is particularly cool in the case of an AutoSave, as indicated by the choice in the message box text. There doesn't seem to be a way to detect AutoSaves either. The good news is that AutoRecover can fully recover the file (since it really is saved before Word crashes), but still, Word shouldn't crash (and the silly dialog should go away, too!)

IMHO the AutoSave should not even trigger the DocumentBeforeSave event because it's not a real "save" -- the user hasn't committed to saving the file yet, so they may not want to give it a name or update a database or call a web service or perform other operations that you would typically do in this event handler. I think that either there should be a separate event for the AutoSave (or at a minimum a flag / parameter that you can query to figure out you're in an AutoSave) or else it should not trigger any events at all.

What do you think? Either way, this little gotcha is something to look out for that you're not likely to come across in normal testing of your application. The default AutoSave timeout for Word is 10 minutes, which probably means it never gets triggered when you're doing your testing. (It repros in VBA as well, so it's not just a managed code / VSTO thing).