An interesting side-effect of this thread is that it has caused me to go back and revisit the code for Normal.dot in all my versions of Word.

Last year, I converted the code for Word 2003 to use a VB 6 DLL for Normal.dot and another for my main global utilities.

I didn't bother to do that for the other versions of Word, but this thread made me think that I'd best assure that the code was compatible for cross-version testing.

So, tho I'm still not using a DLL for the Normal.dot code in earlier versions, I did copy the class to Normal.dot in the earlier versions.

The class worked unchanged with Word 2002, but I eliminated some uneeded code.

For Word 2000, I had to comment out some .Options attributes that do not work in Word 2000.

Ditto for Word 97.

In addition, I had to redesign the code significantly for Word 2000 because, and I had forgotten about this, Word 2000 handles document creation with AutoNew quite differently than in Word 2002 and Word 2003. So I retrofitted those changes to Word 97, Word 2002 and even the DLL in Word 2003.

This also made me realize that, I cannot protect my distributed code from issues caused by users having Auto* macros. Even if I use WordBasic.DisableAutoMacros, I would have to re-enable the auto macros before closing the instance of Word, which gives the user's Auto macros a chance to run when I do not want it to.

For example, if you run the sample code I've had in this thread, some user's will have Auto macros that will cause the blob to appear, just as my AutoExit caused the blob to appear. No way to avoid that.

Perhaps, this is why MSFT has refused to implement a VBA equivalent of WordBasic.DisableAutoMacros?