Office 2007 is official today, so it is time to update my Form Region Sample. The big difference is new methods on the _FormRegionStartup interface. With input from us here in VSTO, Outlook changed the interface to make it easier to use from VSTO addins and more  friendly to managed dlls. The two new methods mean I could remove a bunch of the workarounds in the previous version. The new interface looks like this:

public interface _FormRegionStartup
void BeforeFormRegionShow(FormRegion FormRegion);
object GetFormRegionStorage(string FormRegionName, object Item, int LCID, OlFormRegionMode FormRegionMode, OlFormRegionSize FormRegionSize);
object GetFormRegionIcon(string FormRegionName, int LCID, OlFormRegionIcon Icon); |
object GetFormRegionManifest(string FormRegionName, int LCID);

The first two methods we've seen before, but the next two make it nice. Let's look at GetFormRegionManifest first. This means that the form region manifest that had to be installed on disk and the path registered in the form region section of the registry, can now be stored as a resource in the dll. This means a change in the registration, of course, which I'll cover below. The implementation of this method is quite trivial. We use the name we register it with to identify the actual manifest. It gets returned as a string.

public object GetFormRegionManifest(string FormRegionName, int LCID)
if (FormRegionName == "TQForms.RssFormRegion")
return RSSMessages.Properties.Resources.RSSFormRegion;
else if (FormRegionName == "TQForms.PreviewRssFormRegion")
return RSSMessages.Properties.Resources.PreviewRSSFormRegion;

return null;

The next method – GetFormRegionIcon – solves one problem from before, but introduces another issue. We now no longer have to store icons as Win32Resources, so we can remove the workarounds we had before to make that happen. But instead, we have to convert the icon from a managed object to a COM compatible object that Outlook can use. The implementation from the sample looks like this:

public object GetFormRegionIcon(string FormRegionName, int LCID, OlFormRegionIcon Icon)
if (FormRegionName == "TQForms.RssFormRegion" && Icon == OlFormRegionIcon.olFormRegionIconPage)
return Converter.PictureUtils.ToIPictureDisp(RSSMessages.Properties.Resources.FeedIcon); 
return null;

As you can see, we call a Converter class to turn the resource into an IPictureDisp. Unfortunately, there is no built in .NET way to do this conversion, the Converter class is included in the sample. I'll leave it up to you to check out how it works.

So the xml in the manifest changes a little. Rather than putting in a resource ID, you just put the work addin to tell Outlook to load the particular addin from via the interface. You must do them all the same way – part of getting this work done at that late stage in the cycle was simplifying the assumptions: if one icon is loaded via the addin, they all must be. The xml is here:

<FormRegion xmlns="">
<title>View In Browser</title>

In fact, if you register the form region as coming from the addin, you must load your icons this way. The change in registration makes it much simpler, but it is subtle. Rather than putting a path in the registry, you put the name of the addin – the same name that goes under the Addins key. But you first prefix it with an equals sign (=). This is the clue to Outlook that the manifest and icons are loaded via these new methods. If the addin is registered this way, the new methods *must* be implemented. If it is not registered this way, the new methods will not be called. This is the the registry script:

Windows Registry Editor Version 5.00


Hopefully, you be as happy about these new methods as I am. It makes form regions much easier.