Word Field Evaluation Not Working - REF and IF Fields Converted to Static Text

We’re migrating from JIntegra DCOM to Aspose.Words(JAVA) and encountering a critical issue with Word field processing.
Current Behavior:
• Using mainBuilder.insertDocument(_transientDocument, ImportFormatMode.KEEP_SOURCE_FORMATTING)
• Template contains: {IF { REF OTN92S750Optamt \* MERGEFORMAT } = 0 "N/A" { FORMTEXT }}
• Fields are inserted but show literal field codes instead of evaluated results
• REF fields don’t resolve to bookmark values, IF conditions don’t evaluate

Expected Behavior:
• REF fields should resolve to actual bookmark values from the document
• IF conditions should evaluate (show “N/A” if amount=0, otherwise show the amount)
• Fields should behave like native Word field evaluation

Code Sample:

Document _transientDocument = Rr.toDocument();
_transientDocument.updateFields();
_transientDocument.normalizeFieldTypes();

DocumentBuilder mainBuilder = new DocumentBuilder(doc);
mainBuilder.moveTo(Nodelocation);
mainBuilder.insertDocument(_transientDocument,ImportFormatMode.KEEP_SOURCE_FORMATTING);

Questions:

  1. How to preserve Word field structure when copying content between ranges?
  2. Does Aspose support automatic REF field resolution like Word’s native engine?
  3. What’s the correct way to copy formatted content with live fields intact?
  4. Alternative to Range.copy() and Range.paste() from COM automation?
  5. How should cross-document REF fields be handled when inserting between documents?

@srikantha

Summary
When a fragment that contains nested fields (e.g., { IF { REF … } … }) is inserted into another document, any fields that have already been evaluated are stored as plain text. Consequently the nested field appears as literal code in the target document. To keep the fields live you must insert the source before any updateFields() call and run a single updateFields() on the combined document after the merge.

Why it happens

  1. Document.updateFields() evaluates each field in‑place and replaces the field node with its result (unless the field is locked). If you call updateFields() on the source fragment before inserting it, the REF and the surrounding IF are turned into static text, so the target receives only the field code.
  2. A REF field resolves a bookmark by name in the document that contains the field. When the field is evaluated before the bookmark is present (or after the bookmark has been renamed during import), the REF cannot resolve and the whole nested field remains unevaluated.
  3. Aspose.Words fully supports nested fields, but the evaluation must happen after the source content (including its bookmarks) has been merged into the destination document.

What to do next

  1. Load the source fragment without evaluating its fields
// Load the fragment that contains the IF/REF fields
Document source = Rr.toDocument(); // do NOT call source.updateFields() here

// (Optional) lock the fields you want to keep live
for (Field field : source.getRange().getFields()) {
if (field.getType() == FieldType.FIELD_REF ||
field.getType() == FieldType.FIELD_IF) {
field.setLocked(true); // prevents premature evaluation
}
}
  1. Insert the fragment preserving its structure
Document target = new Document(); // your main document
DocumentBuilder builder = new DocumentBuilder(target);
builder.moveTo(insertLocation); // Node where you want to paste
builder.insertDocument(source, ImportFormatMode.KEEP_SOURCE_FORMATTING);
  1. Confirm that the required bookmark exists after insertion
boolean hasBookmark = target.getRange().getBookmarks()
.get("OTN92S750Optamt") != null;
if (!hasBookmark) {
// The bookmark may have been renamed (e.g., OTN92S750Optamt_0).
// Adjust the field code or rename the bookmark in the source template.
}
  1. Evaluate all fields once, after the merge
target.updateFields(); // resolves REF first, then IF
// In most cases a single call is sufficient; a second pass is rarely needed.
  1. Alternative insertion methods
  • Document.appendDocument(source, ImportFormatMode.KEEP_SOURCE_FORMATTING) – another way to copy the whole document.
  • Both insertDocument and appendDocument perform a deep node copy and keep field nodes intact as long as the fields have not been evaluated beforehand.
  1. Handle possible bookmark name clashes
  • Ensure bookmark names are unique across the whole target document before the final updateFields() call.
  • If Aspose.Words renames a duplicate bookmark (e.g., OTN92S750Optamt_0), the existing REF field will still point to the original name and remain unevaluated. Rename either the source bookmark or edit the field code after insertion to match the new name.
  1. Full minimal working flow
// 1. Load source fragment (contains IF/REF)
Document source = Rr.toDocument(); // no field update here

// 2. (Optional) lock fields you want to stay live
for (Field f : source.getRange().getFields()) {
if (f.getType() == FieldType.FIELD_REF || f.getType() == FieldType.FIELD_IF) {
f.setLocked(true);
}
}

// 3. Load target document
Document target = new Document("Main.docx");
DocumentBuilder builder = new DocumentBuilder(target);
builder.moveTo(target.getSections().get(0).getBody().getLastParagraph());

// 4. Insert source preserving formatting
builder.insertDocument(source, ImportFormatMode.KEEP_SOURCE_FORMATTING);

// 5. Debug: list bookmarks after insert
System.out.println("Bookmark count after insert: " +
target.getRange().getBookmarks().getCount());

// 6. Evaluate fields now that bookmarks are present
target.updateFields();

// 7. Save the result
target.save("Result.docx");

Result – After step 6 the field { IF { REF OTN92S750Optamt \* MERGEFORMAT } = 0 "N/A" { FORMTEXT } } will be rendered as either “N/A” (when the bookmark value is 0) or the actual amount, just as Word would display it. If the field code still appears, double‑check that the bookmark name was not renamed during import and that no document protection or custom field types are interfering.

@srikantha Could you please attach your problematic input and output documents here for testing? We will check the issue and provide you more information.

Looks like we are good on this, the Aspose code is working as expected. Thanks for helping me with it.

1 Like