I had the code to do this, but I guess I didn't save it to git, because I
can't find it now. I changed my whole strategy so as not to rely on
document properties at all. This decision mostly came from the fact that
OOo and LibreO have a long standing bug where they cannot save custom
document properties to a docx file, nor can they read them.
The strategy to update the cached values involves looking for w:instrText,
then finding its w:r parent, then finding that w:r's siblings that contain
w:fldChar where w:fldCharType="end". Then update any w:t tags in any w:r
between those two. This all involves XPath queries on CTNodes.
Since I had to update the word/document.xml main document body with XPath,
and I was in control of the format of the documents entering the system, I
switched to just using plain old text in the word doc and then XPath swap
on that: {INSERT some variable name} . Doing this is easier if you can
highlight the text and change the background color, this will make that
text key it's own w:t tag inside a separate w:r tag. Once the value is
swapped, remove any w:rPr/w:color from the parent w:r. You just have to
look at the XML and write XPath.
On Thu, Mar 7, 2013 at 4:45 PM, Bart Jenkins <[email protected]> wrote:
> Thanks Nick,
> I'm going for plan B which is to use the Word merge-record feature. If I
> add mergerec fields into my document and then point it to a CSV file with
> the needed data to be inserted into my document, it seems to work. Only
> issue now is that Word puts up a popup dialog warning me I am grabbing data
> from an outside source and should I allow that.
>
> Anyway to turn that off?
>
> Thanks
>
> Bart
> On Mar 7, 2013, at 4:42 PM, Nick Burch <[email protected]> wrote:
>
> > On Thu, 7 Mar 2013, Bart Jenkins wrote:
> >> I'm trying to pass in a version string to a field code in some
> boilerplate docx file that I read in at startup. For example:
> >>
> >> XWPFDocument document = new XWPFDocument(new
> FileInputStream("c:\template.docx");
> >> CoreProperties coreprops = document.getProperties().getCoreProperties();
> >> coreprops.setKeywords("Version 1.0");
> >
> > That looks write to change the OOXML level properties
> >
> >> And in my "template.docx" document, I've got a field code that looks
> like the following:
> >>
> >> {INFO Keywords xxx \* MERGEFORMAT} // <-- this is how it looks with
> the field code toggled ON in the word document.
> >>
> >> The 3rd line of code above (coreprops.setKeywords()) does not fail and
> if I re-read the coreprops variable I see that it gets updated. But the
> value is NOT showing up in my document.
> >
> > The office file formats contain caching at various points for
> performance reasons. For example, Excel caches formula values, which often
> catches out people new to POI.
> >
> > Word also caches property values, which is what's biting you here. In
> fact, you can see that by loading a copy of word, going into the document
> properties, and changing them. In most versions of word, with many common
> settings, the property won't change in the text, until you trigger an
> update properties call (right click then update property, if memory serves
> - I don't have word to hand)
> >
> > Sadly, that means you too need to update the cached properties in your
> word document after the change. It's likely a common problem though, so if
> you do manage to write some code to process the word document and update
> the values of all the properties it finds, please do share it back!
> >
> > Nick
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
>
