Issue when upgrading from 11.4 to 11.10 --> GetChildDataSource called when Mergefield has a "."

We’ve recently upgraded from 11.4 to 11.10 and have started to notice different behavior as far as when the GetChildDataSource method gets called.


For example:

We have Mergefields that look like this: {MERGEFIELD FullName.Trim() }

Where FullName is a string property on the current data source. Previous to the upgrade, FullName.Trim() would come in to the GetValue() method and we would evaluate that full expression and return the value. However, after the upgrade, upon hitting FullName.Trim(), GetChildDataSource gets called with FullName as the tableName. It seems that as soon as the merge process sees a “.” in the mergefield name, it decides to call GetChildDataSource. This is obviously not the behavior we want as it affects alot of our templates.

Is this a bug or a feature? If the latter, there must be some way of reconciling this as you are breaking lots of existing code.
Hi Jeff,

Thanks for your inquiry. Could you please attach your input Word document and code here for testing? I will investigate the issue on my side and provide you more information.

Best regards,

Hi Jeff,


Thank you for sending your document and sample project to me via email. I have tested the scenario and have managed to reproduce the same problem on my side. For the sake of correction, I have logged this problem as WORDSNET-7520 in our issue tracking system. We will further look into the details of this problem and will keep you updated on the status of correction. We apologize for your inconvenience.

Best regards,

This is functionality that was working well previously. Can you provide an estimated timeframe for resolution please?


Thank you.

Hi Jeff,


Thanks for your inquiry. This issue is currently pending for analysis and is in the queue. Unfortunately, at the moment I cannot provide you any reliable estimate as to when this issue would be fixed. We will be sure to inform you as soon as your problem is resolved. Sorry for inconvenience.

Best regards,

Hi Jeff,


Unfortunately, I’ve got to say that it is a desirable behavior (see 11.10 release notes) and we are not about to change it back. It seems like you relied on an undocumented feature as there is no mention about that fieldName argument of IMailMergeDataSource.GetValue() method is always equal to the corresponding MERGEFIELD’s name argument anywhere in Aspose.Words reference.

However, there is a way to workaround your issue without any template change. I would advice you to do the following steps.

1. Modify MailMergeDataSource.GetChildDataSource() it always to return null for a nonexistent data source with the specified name as per IMailMergeDataSource.GetChildDataSource() description remarks.

2. Rename MailMergeDataSource.GetValue() to something like MailMergeDataSource.GetValueCore() and make it internal.

3. Create a new version of MailMergeDataSource.GetValue() which simply always returns false/null.

4. At the beginning of MergeFieldHandler.FieldMerging() add MailMergeDataSource.GetValueCore() call with e.DocumentFieldName parameter and set e.Text to the textual representation of the returned value. Note, that FieldMergingArgsBase.DocumentFieldName is always equal (in your case) to the corresponding MERGEFIELD’s name argument in the template document in contrast to FieldMergingArgsBase.FieldName which value is equal to the value of fieldName argument passed to IMailMergeDataSource.GetValue() method in the context of a single MERGEFIELD.

Of course, there are some additional steps to do (as to pass MailMergeDataSource instances to MergeFieldHandler, etc.) but I hope, that this will give you the idea. Please, inform us if this solution does not suit you for some reason.

Regards, Ivan.
Hi Jeff,

It is to update you that on further investigation our development team came to know that they won't be able to implement the fix of your issue. Your issue is now closed with 'Won't Fix' resolution. This means the issue is actually not fixed but closed because we can not fix this now. Please read Ivan's reply for details. I hope, this helps. If we can help you with anything else, please feel free to ask.

Best regards,