Behavior change from Word 2000 to Word 2003 when using Templates?

[djconner]

I have a program that generates a document in Word. It's an "official
document," so one of the requirements was that the output file not be
editable - or at least not *easily* editable. They wanted no options
other than "Print," so what I did is disable all Word's controls other
than printing:

==========
For Each cbar In CommandBars
For Each ctl In cbar.Controls
If ctl.Caption = "&Print" Then
ctl.Enabled = True
Else
On Error Resume Next
ctl.Enabled = False
End If
Next ctl
Next
==========

Kind of kludgy, but it got the job done. And - under Windows 2000/Word
2000 - it never interfered with the use of Word with other documents,
or after the current session.

Now, however, under Windows XP/Word 2003, it seems to be overwriting
the *default* template with the "nothing but a Print Button" setup.
Obviously, not a good thing.

I can fix this immediate problem by deleting the normal.dot file. But
another strange thing is that I can't duplicate the original error
after that. After deleting normal.dot, my program seems to run the
same as it always did, not interfering with Word in general, only with
documents generated by the program. It seems like the problem scenario
only happens once per machine, then never again.

From researching the problem, it *seems* like this line might fix the

problem, but since I can't duplicate the problem, I'm not sure. (And
unfortunately, I don't really have a proper test environment where I
can keep testing and retesting on a new, "clean" system.)

Would this line prevent the program from changing Word's default
behavior? Is the problem that under XP/Word 2003 the default
CustomizationContext is different?

WordApp.CustomizationContext = ActiveDocument

The context is within this code - the "CustomizationContext" line is
the only one I'm changing from previous versions:

============
Set WordDoc = CreateObject("Word.Document")
Set WordDoc = WordApp.Documents.Open(FileName:=TemplateFileName,
Format:=wdOpenFormatDocument, ReadOnly:=True)
WordApp.CustomizationContext = ActiveDocument
WordDoc.SaveAs FileName:=SavePath
============

Does this code look kosher for opening a template and saving a document
to be based on that template, without messing up other stuff?

-David

 

[Steve Rindsberg]

Can't help with the Word programming issues but ...

Have you considered using PDF instead of Word .DOC as your distribution format?
That'd pretty much solve the problem in one go.

Especially as the next version of Word (2007) will make it far more difficult,
if not impossible, to alter the default UI.

As to clean test environments, products like Microsoft's Virtual PC or VMWare
Workstation make this sort of testing child's play.

 

[Cindy M.]

Hi Djconner,

Would this line prevent the program from changing Word's default
behavior? Is the problem that under XP/Word 2003 the default
CustomizationContext is different?

WordApp.CustomizationContext = ActiveDocument

You should ALWAYS use this when making changes to Word's toolbars.
Word can save changes to toolbars in various places, so explicitly
telling it where is a requirement.

Possibly, the default did change after Word 2000 - I'd never have
noticed because I've always know I've needed to use
CustomizationContext.

But as Steve said: PDF would certainly be the much better
solution. Although Word 2003 (and later) do support Information
Rights Management that will let you lock down a document for
everything but what you specify - no macro code involved. That
would certainly be much safer than what you're attempting. Just
try Insert/File on one of these docs...

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17
2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow
question or reply in the newsgroup and not by e-mail

 

[djconner]

Hi Djconner,


But as Steve said: PDF would certainly be the much better
solution. Although Word 2003 (and later) do support Information
Rights Management that will let you lock down a document for
everything but what you specify - no macro code involved. That
would certainly be much safer than what you're attempting. Just
try Insert/File on one of these docs...

At this point, the program is a legacy system, so making major changes
isn't a real option. I just need to have it limp along for a few
months until the new system is in place.

At the time I wrote the program, I did think about PDF, but it didn't
appear to be a practical solution. As far as I could tell, it'd
basically require getting a full $300 Adobe Acrobat license for each
(of about 100) end users. Has this changed (or was I mistaken at the
time?)

Is there anything other than the CustomizationContext I should be
worrying about for the current system? The part I really don't
understand is why (without this line) it only seems to mess up Word's
default behavior *once* - after the problem occurs, and the altered
normal.dot file is deleted, the problem doesn't happen again, and I
can't duplicate the problem.

 

[Steve Rindsberg]

But as Steve said: PDF would certainly be the much better

solution. Although Word 2003 (and later) do support Information
Rights Management that will let you lock down a document for
everything but what you specify - no macro code involved. That
would certainly be much safer than what you're attempting. Just
try Insert/File on one of these docs...

IRM wants more software running on a server accessible from the workstation,
though, doesn't it?

(Then again, the side effect of not having access to the IRMware might be just
the thing wanted ... sneaky.)

 

[Steve Rindsberg]

At this point, the program is a legacy system, so making major changes
isn't a real option. I just need to have it limp along for a few
months until the new system is in place.

At the time I wrote the program, I did think about PDF, but it didn't
appear to be a practical solution. As far as I could tell, it'd
basically require getting a full $300 Adobe Acrobat license for each
(of about 100) end users. Has this changed (or was I mistaken at the
time?)

Probably about right for an all-Adobe solution. I don't think they have any
attractive volume deals for relatively small numbers of users. But they're not
the only PDF-making game in town. Have a look at GhostScript, for example.

Then again, for just a few more months, it might not be worth the bother.

 

[Cindy M.]

Hi Djconner,

Is there anything other than the CustomizationContext I should be
worrying about for the current system? The part I really don't
understand is why (without this line) it only seems to mess up Word's
default behavior *once* - after the problem occurs, and the altered
normal.dot file is deleted, the problem doesn't happen again, and I
can't duplicate the problem.

I don't know why you'd be seeing it only once, especially since I don't
know how the users' workstations are configured as far as Normal.dot
and the Registry are concerned. What I do know is, under normal
circumstances you should NOT be deleting a user's Normal.dot. Critical
customizations such as AutoText and formatted AutoCorrect entries are
stored there.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question
or reply in the newsgroup and not by e-mail

 

[Cindy M.]

Hi Steve,

IRM wants more software running on a server accessible from the workstation,
though, doesn't it?

Yes, it would (Windows 2003 Server). Either internally, or an internet site.
The suggestion was more for the sake of completeness

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply
in the newsgroup and not by e-mail