MailMerge with Duplicated regions

Aspose.Words Product Family
1

Hi,
According to this link: https://docs.aspose.com/words/java/types-of-mail-merge-operations/ it’s allowed two regions with the same name on document.
I have an issue during merge duplicated regions, just my first table is successfully merged.
My document use two tables like this:

Table 1
  Row 1
    Cell 1
	«TableStart:MyProductTable»
	«Name»
	«TableEnd:MyProductTable»

Table 2
  Row 1
    Cell 1
	«TableStart:MyProductTable»
	«Name»
    Cell 2
	«Category»
    Cell 3
	«Price»
	«TableEnd:MyProductTable»

My code:

Products products = entityFrameworkContext.Products.ToList();
document.MailMerge.ExecuteWithRegions(new GenericMailMergeDataSource("MyProductTable", products));

GenericMailMergeDataSource:

I use tableName of ctor on IMailMergeDataSource.TableName get

public class GenericMailMergeDataSource : IMailMergeDataSource
{
    public GenericMailMergeDataSource(string tableName, IEnumerable list)
    {
        _tableName = tableName;

        _list = list.ToArray();

        _index = -1;
    }
	....
}

Result: Ok for table 1, but for table 2 nothing happened.

Table 1
  Row 1
    Cell 1
	Product A
  Row 2
    Cell 1
	Product B
  Row 3
    Cell 1
	Product C
  Row 4
    Cell 1
	Product D...
Table 2

Row 1

Cell 1

«TableStart:MyProductTable»

«Name»

Cell 2

«Category»

Cell 3

«Price»

«TableEnd: MyProductTable»

What’s wrong with my code? I made a mistake about the concept of “duplicated regions”?

Sorry my english.

This message was posted using Page2Forum from Mail Merge with Regions Explained - Aspose.Words for .NET

2

Hi William,

Thanks for your inquiry.

I believe the reason for this is described in the page you linked:

  • Duplicate regions with the same name are allowed. However successfully merging duplicated regions depends on the type of data source being used for mail
    merge:

  • If an IMailMergeDataSource data source or a DataSet is used then duplicate regions will be merged automatically. This is due to the “root” structure of these data source types. Each region in the document is passed to these data sources and merged regardless of whether they are duplicates or not.

  • If mail merge is performed using any other type of data source, for instance a DataTable then the mail merge processmust be executed again to merge each duplicate region. This is because these data source types only merge the first instance of a region in a document. The mail merge process stops after the first region is merged.

This basically means if you are using a DataTable or IMailMergeDataSource to execute mail merge then you will need to execute mail merge again for each duplicate region i.e call MailMerge.ExecuteWithRegions multiple times.

If you are using DataSet or IMailMergeDataSourceRoot then such duplicate regions are merged automatically.

Therefore in your document if you are only expecting one duplicate region then I would just suggest to execute mail merge twice.

If you need any further help, please feel free to ask.

Thanks,

3

Thanks for the reply.

This sentence’s confusing.
“If an IMailMergeDataSource data source or a DataSet is used then duplicate regions will be merged automatically.” Need to be IMailMergeDataSourceRoot instead?

I appreciate your solution, to solve, I write a code to count how many occurrences of TableStart:Product then execute a loop of ExecuteWithRegions.
Curiously, I needed to create a new instance of IMailMergeDataSource on each loop:

While this works:

for (i = 1; i <= _howManyTableStart; i++)
    document.MailMerge.ExecuteWithRegions(new GenericMailMergeDataSource("MyProductTable", products));

it doesnt:

IMailMergeDataSource dataSource = new GenericMailMergeDataSource("MyProductTable", products);
for (i = 1; i <= _howManyTableStart; i++)
    document.MailMerge.ExecuteWithRegions(dataSource);

btw, it’s all fine now. Thanks again.

4

Thanks for this additional information.

Sorry about that, it’s a typo which I will fix now. It’s meant to read IMailMergeDataSourceRoot. I will add another article with code later on to demonstrate this idea further.

The technique you are using now is perfect, it’s great that it’s working now. Just so you know, the reason the second technique is not working is because your internal record id (_index) is not reset with each merge. This means the index is still out of range so no merge happens.

If we can help you with anything else, please feel free to ask.

Thanks,