none
Problem with mailmerge field in header/footer RRS feed

  • Question

  • Hi,

    I have code in one of my projects (C#) that do an automated mailmerge via OpenXML on word.dotx. The datasource is in the database and the C# code does the magic of changing the text value of the MailMerge field. 
    Everything works nicely, even when i open the document in word. But if I do an printout of the stored document, the mailmerge fields in the header/footer section is reset to their original value. 

    I have tried to print with word.Application.printout and using StartInfo.Verb = "PrintTo", but with the same result. All mailmerge fields in the main document is fine, but header/footer is reset. 

    Can anyone help me out here?

    /Svein Thomas

    Friday, December 4, 2015 3:06 PM

Answers

  • Two questions:

    1. Does your code also handle the fields in the header and footer Parts or do you only work with the MainDocumentPart?

    2. Does your code REMOVE the mergefields? Or how, exactly, does it write the data into the document?

    In Word's world, field codes (such as mergefields) update when certain events are triggered. Two major events are viewing headers/footers and printing. This will trigger fields in the header/footer to update, but not necessarily in the document body. The reason for this is that important fields such as page numbering, dates, file name, etc. are usually in the header/footer and need to be current.

    This means the merge fields in the header/footer will update, even when fields in the body do not. Mergefields will revert to their default setting and this is correct behavior.

    Correctly, your code should be replacing the merge fields with the data so that there are no merge fields left in the document when it's opened. Even better would be to not use MergeFields at all, use Content Controls as the "data targets", instead.

    Alternatively, the merge fields can be LOCKED so that they cannot update.


    Cindy Meister, Office Developer/Word MVP, <a href="http://blogs.msmvps.com/wordmeister"> my blog</a>

    Friday, December 4, 2015 5:26 PM
    Moderator
  • Hi Svein,

    As Cindy suggested, we can replace the merge fields with content control or the data value directly. Here is an helpful article about Mail Merging using Open XML for your reference:
    Mail Merging with a Custom Client Using the Open XML SDK 2.0

    Regards & Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, December 8, 2015 6:35 AM
    Moderator

All replies

  • Two questions:

    1. Does your code also handle the fields in the header and footer Parts or do you only work with the MainDocumentPart?

    2. Does your code REMOVE the mergefields? Or how, exactly, does it write the data into the document?

    In Word's world, field codes (such as mergefields) update when certain events are triggered. Two major events are viewing headers/footers and printing. This will trigger fields in the header/footer to update, but not necessarily in the document body. The reason for this is that important fields such as page numbering, dates, file name, etc. are usually in the header/footer and need to be current.

    This means the merge fields in the header/footer will update, even when fields in the body do not. Mergefields will revert to their default setting and this is correct behavior.

    Correctly, your code should be replacing the merge fields with the data so that there are no merge fields left in the document when it's opened. Even better would be to not use MergeFields at all, use Content Controls as the "data targets", instead.

    Alternatively, the merge fields can be LOCKED so that they cannot update.


    Cindy Meister, Office Developer/Word MVP, <a href="http://blogs.msmvps.com/wordmeister"> my blog</a>

    Friday, December 4, 2015 5:26 PM
    Moderator
  • Hi and thank you for you answer Cindy.

    My code does not replace the mergefields, it only replaces as written, the text element of the mergefield. It does not replace the whole mergefield, since this can contain formating etc. But i would like to repalce the whole mergefield if you have any good suggestion on how to do this.

    Using Content Controls would be an solution, but then again, we have to change alot of mailmerge documents. So I rather not go with that solution. 

    I do aggregate through header/footer parts like this:

                fldChars = docGenerated.MainDocumentPart.HeaderParts.Aggregate(fldChars, (current, part) => current.Concat(part.RootElement.Descendants<FieldChar>().ToList()).ToList());
                fldChars = docGenerated.MainDocumentPart.FooterParts.Aggregate(fldChars, (current, part) => current.Concat(part.RootElement.Descendants<FieldChar>().ToList()).ToList());

    When i Open the document (the temporary saved document) right before printout, the mergefields are correctly filled out. But when i try to print out, the fields are reset as i point out in your answer. 

    So the solution for us will be to replace the entire mergefield. Please link me to any good solution doing this, both for complex and simple mergefields.

    /Svein Thomas

    Monday, December 7, 2015 12:30 PM
  • Hi Svein,

    As Cindy suggested, we can replace the merge fields with content control or the data value directly. Here is an helpful article about Mail Merging using Open XML for your reference:
    Mail Merging with a Custom Client Using the Open XML SDK 2.0

    Regards & Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, December 8, 2015 6:35 AM
    Moderator