The signature for the Application.MailMergeAfterRecordMerge event looks like this:
void Application_MailMergeAfterRecordMerge(Word.Document Doc)
{
}
While I would have expected the Document referenced in the Doc parameter to be the newly created merged document, it is actually a reference to the document from which the merge occurred. In other words, it’s not really all that useful.
(Long story short: the property you need is ViewMailMergeFieldCodes. Set it to 0 to enable preview; -1 to disable preview)
The mail merge process in Microsoft Word is a bit of a bear to automate sometimes. I suppose I should be thankful that it can be automated at all, but there are bits of it that are very poorly documented, requring a bit of trial and error to work with. It doesn’t help that most Office interop documentation leans toward Visual Basic…
Anyway, today’s issue was attempting to programmatically Preview the results of a Mail Merge in a C# VSTO project, like the button in the ribbon:
Big surprise: Document.MailMerge doesn’t contain any properties or methods with the word “preview”
Turns out there is a property called ViewMailMergeFieldCodes that does what we need, but in reverse. Microsoft’s documentation states:
This property returns True if merge field names are displayed in a mail merge main document, and False if information from the current data record is displayed
Trouble is, the field is an int, not a bool! A little debugging to the rescue:
When this field is set to -1, Preview is disabled, and the field codes are displayed.
When set to 0, Preview is enabled, and the record data is displayed.
To switch the displayed record, change Document.MailMerge.DataSource.ActiveRecord.
Now if only there was an event that fired when the record changed…
I need to create some objects that will allow me to access columnar data by header name. The access looks something like this:
class ParentObj {
string[] columnNames;
ChildObj[] Children;
}
class ChildObj {
Dictionary<string, string> Items;
}
All the child dictionaries will have the same set of keys, matching the column list from the parent.
Now this particular object is going to be used on computers that are resource constrained, and could contain large quantities of data. My big concern was should I actually use separate dictionaries, or should I just store the values in an array, and lookup the column number from a single dictionary.
After trying both methods with very large random data, I found the memory usage to only increase 10megs using separate Dictionaries. Certainly not worth the added complexity of managing my own Dictionary implementation.
My next question was if the CLR was wasting a bunch of memory on a bunch of duplicate keys. CLR Profiler to the rescue!
I modifed my test program to be able to either use the same keys in all child objects, or use random keys as well. After making all the strings the same size, it was clear that .NET does not keep a separate copy of each of the duplicate strings around:
Object memory when all keys are the same:
Object Memory when the keys are random:
So in conclusion, using many dictionary instances with the same set of keys does not result in a significant amount of duplicate data in memory (or memory waste).