Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||WW8: docvariable fields not imported|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|Priority:||P3||CC:||bruno.braz.goncalves, issues, mhayes|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
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 defect
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 future?
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 namespace. 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
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 fields. 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
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: Steps: 1. import Word document (.doc) with Custom Fields to Writer 2. in Writer save document as Microsoft Word 97/2000/XP (.doc) Results: . 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. ***