dsofile CustomProperties in document header

[RikardM]

We are currently using dsofile.dll to read and write custom properties on
word documents. When a new document is uploaded to our website we update a
custom property that we could call myVersion which stores that documents
current version number. This custom property is then added as a field to the
document header so when you open the document you can see what version this
document is and this value is then automatically maintained by the server.

How ever, updating the custom property with dsofile.dll doesn’t make the
field in the document header update to show the correct value in myVersion.
To be able to show the correct value the user will have to manually update
the contents of the field by for instance right clicking the field and
clicking [update field].

Making an add-in for Word that you can install on each client doesn’t work
since Word doesn’t run add-ins when you open a word document in embedded mode
(in Internet explorer) using office automation on the server will not work
either since it doesn’t work with our current through put of documents on the
server, Microsoft have also put up some strong reservations against using
office automation in a server environment since it’s not designed for it.

What we wish to do is refresh the field inside the word document and then
resave the document so that the content of the field shows the correct value
when the document is opened.

Thanks in advance
/Rikard

 

[Cindy M -WordMVP-]

Hi =?Utf-8?B?UmlrYXJkTQ==?=,

How ever, updating the custom property with dsofile.dll doesn’t make the
field in the document header update to show the correct value in myVersion.
To be able to show the correct value the user will have to manually update
the contents of the field by for instance right clicking the field and
clicking [update field].

What we wish to do is refresh the field inside the word document and then
resave the document so that the content of the field shows the correct value
when the document is opened.

I'm not quite clear on whether your solution will allow automating the document
in a Word window, but...

Generally, fields in the header/footer areas will update if you switch into/out of
print preview or the print layout view.

If that doesn't work, then you'd need to use code that access the header/footer
range and forces a field update. Something along the lines of:

Dim rng as Word.Range
Set rng = ActiveDocument.Sections(1).Headers(wdHeaderFooterPrimary).Range
rng.Fields.Update

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
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

 

[RikardM]

Thank you for your response.

You are correct, switching in and out of Print Preview will update the
fields in the header and footer area. This however will require user
interaction. Every time a user views a document they will have to switch in
and out of the Print Preview so this is not a solution for us. But it is
something we can tell our users to do while we look for a better solution so
it’s still helpful.

We currently show the documents to our users by sending the document in a
bit stream to an empty frame in internet explorer. Is it possible to open
word documents in embedded mode on a client computer with some kind of
property set so the document opens up in the Print Preview mode?

The code presented is more or less the code we use today; we have inserted
this into normal.dot which is the only way to automatically run an addin if
you open a word document embedded. Since this is word VBA code I assume we
have to either run it together with normal.dot or with word-automation on the
server.

Updating normal.dot with macro code that runs automatically every time a
word document is opened up has a few problems and the task to install it
everywhere is a problem in it self so we wish to avoid this. And running
word-automation in the server is something that Microsoft strongly recommends
against, and there is no way that will work with the current throughput of
documents on the server anyway.

What we are looking for is a way to update custom fields in the header and
footer of a document without user interaction and without using
word-automation on the server or running macro code inside normal.dot.

Hi =?Utf-8?B?UmlrYXJkTQ==?=,

How ever, updating the custom property with dsofile.dll doesn’t make the
field in the document header update to show the correct value in myVersion.
To be able to show the correct value the user will have to manually update
the contents of the field by for instance right clicking the field and
clicking [update field].

What we wish to do is refresh the field inside the word document and then
resave the document so that the content of the field shows the correct value
when the document is opened.

I'm not quite clear on whether your solution will allow automating the document
in a Word window, but...

Generally, fields in the header/footer areas will update if you switch into/out of
print preview or the print layout view.

If that doesn't work, then you'd need to use code that access the header/footer
range and forces a field update. Something along the lines of:

Dim rng as Word.Range
Set rng = ActiveDocument.Sections(1).Headers(wdHeaderFooterPrimary).Range
rng.Fields.Update

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)


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

 

[Cindy M -WordMVP-]

Hi =?Utf-8?B?UmlrYXJkTQ==?=,

What we are looking for is a way to update custom fields in the header and
footer of a document without user interaction and without using
word-automation on the server or running macro code inside normal.dot.

I'm afraid there's not much hope of that...

It's theoretically possible to put code in the document, itself, but I think
that won't execute automatically when you open in embedded mode.

You might try automating just running that macro from the server. Since the
automation wouldn't directly automate the Word application beyond setting up
an automation link, sending the Application.Run command, then breaking the
automation link, it shouldn't cause any real problems (no message boxes or
such).

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
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