Unsaved changes in the Normal template

[Howard Kaikow]

Due to sloppily written 3rd party apps/add-ins/macros, many users are troubled by the message asking whether they want to save changes to the Normal template.

In many/most cases, one has to know how to examine VBA code to determine the cause of such changes.

I was thinking of doing the following in a class, but I'm not sure whether
this would help or further annoy users.

I would include code that checked for a dirty Normal template at class
startup AND before each macro runs.

I would issue a message asking whether the user wanted the macro to save the changes now, and also give the user an opportunity to cancel the macro. The choices would be Yes, No, Cancel.

Is the above useful?

In any case, I will include code that checks for changes in Normal when the
class terminates. This is to assure that my code does not cause any unintentional changes in the Normal template.

[Jacob Hilderbrand]

It would probably be easier on your users if they didn't have a choice. Can you just automatically save or not save the Normal template without any user input?

[Howard Kaikow]

It would probably be easier on your users if they didn't have a choice. Can you just automatically save or not save the Normal template without any user input?

Yes, but I consider that a No No, unless the changes were a result of my own code.

If the Normal template is already dirty when my code starts, I don't know whether to save those changes.

If I dirty the template with my own code, and I would rarely see a need to do so, then I would silently save, but the query is for the case in which there are unexpected changes as a result of my code.

The bigger issue is what to do with an already dirty Normal template.

[Jacob Hilderbrand]

It might be easier to put your code in another template and not use Normal.dot. That way you can just worry about your code in your template and forget about what else might be happening in the Normal template.

[Howard Kaikow]

It might be easier to put your code in another template and not use Normal.dot. That way you can just worry about your code in your template and forget about what else might be happening in the Normal template.

I've been doing that for years.

I went one step further a few months ago and compiled the code into a DLL.

However, just because code is not in the Normal template does not prevent the code from intentionally, or not, modifying the Normal template.

Indeed, it even matters whether the template is global or not.

I'm currently working with a template that, if loaded in Word's Startup directory, has no impact on the Normal template.

However, if directly attached to a document, the act of instantiating the class in the associated DLL seems to cause a change in the Normal template.

Same code, only difference is how the template is loaded.

I'm going to try to reproduce the behavior with a simpler DLL and/or code in a class in Word itself, instead of the DLL.