Issue 9544 - WW8: docvariable fields not imported
Summary: WW8: docvariable fields not imported
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: 643C
Hardware: PC Windows 2000
: P3 Trivial with 4 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: ms_interoperability, oooqa
: 109591 110407 (view as issue list)
Depends on:
Reported: 2002-11-26 09:35 UTC by faltrion
Modified: 2017-05-20 11:22 UTC (History)
3 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---

a simple Word document with 1 docvariable named "test" with the value of "hello" (30.00 KB, application/octet-stream)
2002-11-26 09:38 UTC, faltrion
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description faltrion 2002-11-26 09:35:30 UTC
If word documents that contain docvariables is opened in OOo hte docvariables
are lost, only their values are left in the resulting file.
It has been described in issue 3166 as unsolvable since no such variables exist
in OOo, however OOo has other fields that does not exist in Word, one of those
fields are the Variables/user fields, I suggest that these could be used instead
of docvariables since they have almost (afaics) the same usage.

When opening an word document with docvariables the docvaraibles should be
converted to these user-defined fields, and when saving the document back to
word, they should once again be converted to docvariables, thus making it easier
to import word documents and work with them as word documents (som of us have to
do that)

I'll try to add a word document that contains one of these docvariables.
Comment 1 faltrion 2002-11-26 09:38:39 UTC
Created attachment 3771 [details]
a simple Word document with 1 docvariable named "test" with the value of "hello"
Comment 2 ingenstans 2003-07-18 10:41:51 UTC
This seems to me a sensible enhancement suggestion, rather than a 
Comment 3 stefan.baltzer 2003-07-18 18:05:11 UTC
SBA->CMC: Same in OOo 1.1RC. Is there a meaningful solution for the
Comment 4 stefan.baltzer 2003-07-18 18:05:39 UTC
Target OOo 2.0
Comment 5 caolanm 2003-07-21 13:34:16 UTC
cmc->ama: Word has a variable namespace addressed by fields set and
ref which is equivalent with our fields set and show.

The namespace addressed with this docvariable field is a seperate one
whose values are assigned in vba, e.g. load the bugdoc in word and go
to the vba macro editor. This namespace is also seperate from the word
DocProperty field namespace which is equivalent to our DocInformation

As the variables are assigned in VBA unless we could execute the VBA
then we won't be able to display the values of these variables (hence
the mhayes cc addition), and I suspect that we might need a seperate
field for addressing these variables from a writer document because
user field doesn't to my mind match this behaviour.
Comment 6 andreas.martens 2003-07-24 14:43:40 UTC
Mike, Caolán: Is there a possibility to get the names and the value of
the variables without running the VBA macro?
Comment 7 lohmaier 2003-07-27 11:44:18 UTC
added ms_interoperability
Comment 8 andreas.martens 2003-09-12 14:55:47 UTC
If we spent a new field type, does this help (without VBA conversion)?
Comment 9 caolanm 2003-09-15 11:12:44 UTC
As far as I can see the only way to get the correct information about
what the variables actually are is through parsing/running the VBA
itself. Without being able to do this a new field isn't really enough,
because we won't have the correct value to set. *But* what is true is
that word will put the last known value of the field in the field
result of the field. So we *could* use this cached value as the
default value to set for the field (but of course its only a hack).
Comment 10 andreas.martens 2003-09-16 15:33:38 UTC
If it's only a hack would it be necessary to create a new field type
for that? Or could you use our variables/user fields for this hack?
Comment 11 andreas.martens 2003-09-18 13:56:31 UTC
Comment 12 caolanm 2003-09-18 14:23:42 UTC
Hmm, I think that we should have a seperate field if possible,
otherwise we could have both
a) name collisions between this variable space and the other
set/ask/ref namespace that is currently imported into variables/user
b) difficulty in roundtripping docvariable fields back to being
docvariable fields, as they'ed end up back in word as set/ref fields
if munged into our existing variables/user fields.
Comment 13 andreas.martens 2003-09-18 15:41:22 UTC
What do you think about such new fields?
Comment 14 Oliver Specht 2003-09-23 09:06:30 UTC
I think that Henning can easily add such a field type ;-)
Comment 15 openoffice 2003-09-25 11:08:48 UTC
Comment 16 openoffice 2003-11-24 09:28:52 UTC
Do we need a new field or is a new member for the user field
containing the namespace enough?
Comment 17 openoffice 2004-02-04 16:52:09 UTC
estimated effort
Comment 18 andreas.martens 2004-07-20 12:59:41 UTC
Because of a shortage of resources we have to retarget this issue to OOo later.
Comment 19 bgoncalves 2006-08-17 11:34:42 UTC
OO Writer 2.0.3 is almost there.

Until this compatibility is completely provided it is hard to switch from MS
Word do OO Writer.
1. My company use MS Word format to produce documentation, as many companies do
(view issue 5091 in project 'qa').
2. Every document has at least 6 Custom Fields.
3. If I edit a document in Writer I will lose all these Custom Fields.

Please check my simple test with Writer 2.0.3:

1. import Word document (.doc) with Custom Fields to Writer
2. in Writer save document as Microsoft Word 97/2000/XP (.doc)

. After step 1: the Custom Fields are successfully imported to Writer as
Variables and are dynamic in text in page.

. After step 2: the Variables are successfully exported to Word as Custom Fields
BUT ARE NOT dynamic in text, i.e., the variable text is all static in the page!

I believe this issue is related to issue 25915.
Comment 20 michael.ruess 2007-07-17 13:48:00 UTC
Made summary much more significant.
Comment 21 michael.ruess 2010-02-25 14:40:25 UTC
*** Issue 109591 has been marked as a duplicate of this issue. ***
Comment 22 michael.ruess 2010-03-26 11:06:52 UTC
*** Issue 110407 has been marked as a duplicate of this issue. ***
Comment 23 Marcus 2017-05-20 11:22:45 UTC
Reset assigne to the default "".