Uncategorized

The integration between SharePoint and Microsoft office contiunes to improve with every successive release, but as of Office 2010 and SharePoint 2010, there is still a bit of feature gap when it comes to automation.

When a document originates from within SharePoint it is not too bad – you have to do a little CustomXMLPart trickery to set the properties. But what if your file is a SharePoint virgin?

The adding a document to sharepoint adds at least 3 additional Custom Xml Parts to the Word Document – one of them big, complex and guid-filled. To generate these parts would be a bit of a nightmare.

Turns out, you don’t need all of the xml to pre-populate fields. Nor do you need any guids. Here is all the XML you need:

<?xml version="1.0"?>
<p:properties xmlns:p="http://schemas.microsoft.com/office/2006/metadata/properties" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pc="http://schemas.microsoft.com/office/infopath/2007/PartnerControls">
  <documentManagement>
    <SharePoint_x0020_ColumnName>Text Value</SharePoint_x0020_ColumnName>
  </documentManagement>
</p:properties>

I will leave it to you to figure out the column names (hint – spaces become “_x0020_”).

Store that xml bit in a string (say, xmlString), and call Document.CustomXMLParts.Add(xmlString);
Now, when the document is saved to sharepoint, the fields will be pre-populated, all the appropriate xsd and guids updated, and the user gets no errors about missing required fields!

(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).