We have some merge fields in a table which we merge into singularly instead of using the ExecuteWithRegions method.  In other words, we'll do something like (C#):

            Document.MailMerge.Execute(new[] { "Field1" }, new[] { "11/30/2009" });

We do this even though Field1 is inside a cell that is part of a Table.  This operation works in Aspose 6.6, and I believe Aspose 7.0 although I didn't test it in Aspose 7.0.  However, in Aspose 8.0 this operation ignores the merge operation.  No exception is thrown.

I suspect I can get around this issue by using ExecuteWithRegions, but I'm disturbed that this behavior just stopped working in the new release.  We didn't upgrade to 7.0 because some functions had regressed and in this case it appears we have another case of a previous working functions behaving differently.

I attached a test project that I believe illustrates the problem.  Run it against 8.0 then 6.6 (or 7.0) and let me know if you see the same issue.

Thanks, 

Ed 

Hi Ed,

Thank you for your request. This is not a bug but a changed behaviour indeed. Execute now ignores all the fields inside a merge region because it is ExecuteWithRegions what is responsible to merge such fields. Sorry if we did not mention that in the documentation, we will fix it ASAP.

However, why would you need to populate a field that is inside a region using Execute?

Ah, and what are the regressions in 7.0 you have mentioned? I hope they might have been fixed in 8.0, otherwise please let us know so that we could fix them shortly. We normally don't allow regression bugs to appear thanks to several thousands unit tests, so we are quite interested in quick eliminating such ones when they appear nevertheless.

Thanks.

OK, so what you're telling me is that the reported behavior is not a bug but an undocumented change in behavior.  I'll have to remember to use that with my clients :-)

I concede that merging fields in a table cell singularly is unintuitive, so I can't completely fault you guys for overlooking that during testing.  In answer to your question, we didn't set out to code it that way.  We had a number of changing requirements and tight deadlines while developing our reports.  I believe the table data was originally slated to be a list, changed to a single item and projected to be changed back to a list in 2010.  Since the Aspose component permitted us to perform Execute inside a region we left the code that way in anticipation of eventually going back to a ExecuteWithRegions.  The change in Aspose's behavior should have certainly been documented in the release notes, but you already mention that. 

I'll modify our code to get it to work with 8.0.  One of our challenges is that we have a lot of report pages.  Since the 8.0 behavior change is silent (i.e. doesn't throw an exception) I have to be careful to catch all relevant cases.  But, that's my problem.

In answer to your last question, the 7.0 regression I referenced was bug #11189 which was fixed in 8.0.

Thanks for getting back to me so quickly.

Regards,

Ed

It should have been documented actually, I do agree :) I registered it as defect #11945 and it will be fixed in the next release. Sorry for that.

This kind of behaviour change should not throw an exception I believe. There might be fields with the same names inside and outside of regions, and Execute should merge the latter ones only without throwing.

The issues you have found earlier (filed as 11945) have been fixed in this update.