We have identified that formatting applied to mail merge command (MERGEFIELDS) within letter templates does not appear to be working in Aspose word 24.6 version. The letter templates make use of the # 00.00 to remove the sign (+) from the following fields: QAR001 FCA_REG_EOMARR - D02788 FCA_REG_EOMCB - D02789 This functionality works correctly in Aspose version below 24.5 i.e. it works fine with 24.4 version of Aspose . As an example, 31206.47+ from the template xml would be displayed as 31206.47 within the letter content. Tests have proven that regardless of what the formatting is set to in the mergefield command, the formatting requested is now ignored. For example, the formatting was changed to # ‘000000000’ as a test. This should have resulted in number output that was stripped of decimals and the sign; however, the value was still taken directly from the xml without any further formatting e.g. 31206.47+. The templates and XML for letter are attached/Upload.
Could you please suggest on this?
evidence.zip (54.9 KB)
@UGSINonLinc
It seems that you are experiencing an issue with the formatting of currency fields during the mail merge operation in Aspose.Words version 24.6.0.0. Specifically, the formatting commands you are using, such as \# 00.00
, which should remove the trailing plus sign from the currency values, are not functioning as expected in this version. This issue does not occur in earlier versions, such as 24.4.
Here are a few suggestions to troubleshoot and potentially resolve the issue:
-
Check for Updates: Ensure that you are using the latest version of Aspose.Words. Sometimes, bugs are fixed in newer releases, so it might be worth checking if a newer version than 24.6.0.0 is available.
-
Review Formatting Syntax: Double-check the syntax of your formatting commands. Ensure that there are no typos or incorrect characters in the merge field commands.
-
Test with Different Formats: Since you mentioned that changing the formatting to \# '000000000'
did not yield the expected results, try experimenting with other formatting options to see if any of them work correctly.
-
Revert to Previous Version: If the issue persists and is critical for your application, consider reverting to version 24.4 where the formatting worked as intended.
-
Contact Support: If none of the above solutions work, it may be beneficial to reach out to Aspose support directly with your specific issue, including the templates and XML data you are using. They may provide insights or fixes for this version-specific problem.
If you have any further details or specific examples of the merge fields you are using, feel free to share them for more tailored assistance.
@UGSINonLinc This looks like an expected behavior. Data in your XML is the following:
<?xml version="1.0" encoding="utf-8"?>
<LetterData>
<FCA_REG_EOMARR><![CDATA[ 31206.47+]]></FCA_REG_EOMARR>
<FCA_REG_EOMCB><![CDATA[ 282872.86+]]></FCA_REG_EOMCB>
</LetterData>
31206.47+
value is not a valid double
value and Aspose.Words considers it as a string
, so number format switches are not applied. To get the expected output it is require to remove +
from the end so the value was recognized as double
. You can trim the +
sign in IFieldMergingCallback
:
DataSet ds = new DataSet();
ds.ReadXml(@"C:\Temp\data.xml");
Document doc = new Document(@"C:\Temp\in.docx");
doc.MailMerge.FieldMergingCallback = new MyCallback();
doc.MailMerge.Execute(ds.Tables[0]);
doc.Save(@"C:\Temp\out.docx");
private class MyCallback : IFieldMergingCallback
{
public void FieldMerging(FieldMergingArgs args)
{
args.FieldValue = ((string)args.FieldValue).TrimEnd('+');
}
public void ImageFieldMerging(ImageFieldMergingArgs args)
{
// Do nothing
}
}
data.zip (291 Bytes)
in.docx (22.4 KB)
out.docx (17.0 KB)
Hi Alexey,
Thanks for your response.
I would like to understand why this behavior has changed compared to older versions of Aspose.Words. Previously, the same values were correctly handled(trimmed) by ASPOSE versions till 24.4 and issues has been encountered from Aspose 24.5 version onwards even though same template and values were used.
Kindly note the same values were correctly handled without requiring manual trimming of the +
sign in previous versions of ASPOSE (<24.5).
Could you please suggest?
@UGSINonLinc We will further investigate the case.
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): WORDSNET-28083
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.