Advanced Outlook Regions for VSTO (VB.NET, C#):
minimize, dock, hide and share between forms
Add-in Express™ Regions
Add-in Express Regions - basic concepts
Add-in Express Regions for Microsoft Outlook and VSTO is an extension for Visual Studio Tools for Office that allows you to embed .NET forms into Outlook Explorer and Inspector windows. With Add-in Express Regions, you can customize several Outlook panes, namely:
Add-in Express Regions supports creating regions for Outlook forms (form regions) as well as for Outlook views (view regions) in Outlook 2013, 2010, 2007 and 2003.
Your regions are shared
When you create and design your regions based on Add-in Express Regions, you really operate on forms, Outlook-specific descendants of Windows.Forms.Form. Generated by a special wizard, which is part of Add-in Express Regions, only these forms can be embedded into regions to extend the Outlook UI.
Add-in Express shares all regions between all forms created by all loaded add-ins that are based on the Add-in Express technology. Since one Outlook region can contain several forms, the provided region header allows users to navigate between all forms hosted by the region. By default, the region header displays a list of hosted forms and Forward / Backward buttons that activate the next and prior forms. In addition, the region can display a Close button that closes the active form.
Regions can be resized, minimized and hidden
Any Add-in Express region can be resized, minimized and hidden by the end-user:
Enable drag-and-drop for your regions
All embedded forms can be dragged between regions within a particular Outlook window. You as the developer have full control over which of your regions can be dragged, and to which areas of the various Outlook windows. Dragged regions seamlessly integrate into existing regions by sliding into the selector so that only one region is visible at a time - all controlled by the end-user.
End-user experience and region persistence
Since the end-user may resize, hide or minimize regions, or drag them between Outlook panes, Add-in Express ensures that the positions, states and sizes of Regions are stored in the registry when the end-user closes the current Outlook session. When the user next opens Outlook, Add-in Express restores all settings of the region and restores the region configuration that was earlier customized by the end-user.
Binding your region to the context
When you use the Regions framework, you can bind your regions to various Outlook contexts so that they are only displayed when you think it is most appropriate. For example, you can show your regions in one or more Outlook folders depending on the folder names; or for specific folder types based on their DefaultItemTypes or DefaultMessageClasses properties. You can even bind your regions to specific inspector types by their CurrentItem.Types or CurrentItem.Classes properties. This context-sensitivity allows you to avoid having to trap many Outlook events such as FolderSwitch, NewInspector, NewExplorer, SelectionChange, etc. You just specify some properties of your regions instead. Simply put, by associating your regions to Outlook contexts you can quite easily reduce the complexity of your code.
Outlook view regions, instancing and forms cache
Each time when the end-user opens an Inspector window, Add-in Express creates new instances of the forms that are bound to that window (e.g. by the Inspector type). That instance will be destroyed when the end-user closes the Inspector window or closes the form by the Close button on the region header. Although this is a standard procedure for Inspector regions, questions about form instancing may arise once we have a closer look at view regions.
On the one hand, you may want to create a region whose content is global for the entire session and does not depend in any way on the folder currently displayed by the Explorer window. For instance, you can create a form that will let the end-user switch between folders in some particularly sophisticated way. In this case, for each Explorer window there should be only one instance of your form. On the other hand, the requirements for your region will be such that you need to create an instance of your form every time the end-user switches to an appropriate folder. Finally, to accelerate the navigation between folders, you will probably want to have the form hidden when the end-user moves from a certain folder to another and force it to reappear when the end-user returns.
The three scenarios described above are gracefully handled for view regions that are based on Add-in Express by using the forms cache and with the following instancing strategies: