IronShay

How to the disable background-saving and auto-recover features in Word 2003

A few days ago I was given a request to disable the automatic saving capability of Word via an addin, so the document will be saved only when the user tells it to.

The solution for this is quite simple, but the names of these properties are quite tricky so I've decided to share it with you.

Here is the code you need to add:

// Disable the background save feature
Application.Options.BackgroundSave = false;
// Disable the auto-recover feature
Application.Options.SaveInterval = 0;

Line 2 is straight forward - setting the BackgroundSave property to false disables this feature.
Line 4 is quite tricky - when the SaveInterval property is set to 0, it means that auto-recovering is disabled. Any other number will represent the minutes between every auto-recover operation.

All the best,
Shay.

My Addin has changed Normal.dot? Huh?

When you develop a large Microsoft Word addin, you might get to a point when you get a message like "Normal.dot has changed, would you like to save?" when you try to close Word.

I'll put it straight - your addin isn't a pure soul and it is the trouble maker... :)

It can be caused by lots of lots of different things - toolbars, styles and everything that goes to the global template AKA Normal.dot. 

This behavior is simple to explain - when you set something which is related to the Normal.dot, Word sets a flag that the global template has been changed and needs to be saved. This flag is the Application.NormalTemplate.Saved.

Even if you remove everything you've added before the document is closed, the flag will still indicate that a change has been made. If you don't want your users to get the irritating message of "Normal.dot has been changed, please save...", you should set this flag yourself - 
In the ThisDocument_Shutdown event handler, add the following line of code:

Application.NormalTemplate.Saved = true;

This actually deceives Word to think that Normal.dot has already been saved, which means that the "Normal.dot has changed" pop up will not come up.

Pay attention to a few things:

• Put this line at the end of the shutdown process (just in case you touch the Normal.dot properties during this method).
• Do remove everything you've added, so you won't leave any trails.

Last thing - I've seen a strange behavior in one of my clients. Even after setting the flag to true, the "Normal.dot has changed" message still came up. Only deleting all instances of Normal.dot on the computer fixed this. I guess something has corrupted the global template... So beware of that.

Hope it helps,
Shay.

Poor Loading Time for Word 2003 Addin

... or When "So Long" Means Goodbye.

During the last couple of weeks I've been struggling with VSTO and my code, trying to find an answer to the long duration it was taking for Word to load with my addin, which wasn't such slow and clumsy.

After testing my smart document from almost every possible angle, a colleague of mine suggested to check the automatically generated code that VSTO adds to every new smart document you create.

So I did. This automatically generated code lies within the ThisDocument.designer.cs file, which you'll be able to see only after clicking the "Show All Files" button in Visual Studio.

In this file, there is the Initialize method which does all the background initializing for you. I'd put timers there and found out that the reason for the long loading time was the InitializeCachedData method.

Yupe, it's the deserializtion of the document's cached items that was taking so long.

WATCH OUT FROM SERIALIZATION!!!

This is pretty much the message I'd like you to absorb... In my smart document I have about 10 cached items, including a list of longs, a list of strings and a list of typed datasets. The InitializeCachedData took on my machine 5-6 seconds and on some other machines it took up to 30 seconds! What I did eventually, was changing all the list cached items to strings and managing the serialization and deserialization of my cached items by myself. This reduces the execution time of InitializeCachedData in about 66%!

In conclusion,

1. Variables you don't need to cache, don't cache.
2. Keep your cached items as small in size as you can.
3. If possible, make all your cached items the same type and if possible, make it a value type.

Remember, "so long" means goodbye. And in terms of your product, this is bad, very bad.

Take care,
Shay.