Microsoft Outlook 2007 Issues for Developers
Along with the major extensibility improvements in Outlook 2007 come various problems. The links at right provide references for the major new features. Below you'll find information on potential issues to consider, especially if you're testing applications that were developed for earlier versions.
Office 2007 Service Pack 2 targets Outlook with a long list of performance improvements related to .ost and .pst files, startup, shutdown, and folder switching. For details, see:
For information on earlier updates see:
These are the key design changes for Outlook 2007 developers:
- Vastly expanded object model - check Outlook VBA Help for articles and samples
- The "ribbon" UI in Inspector windows
- Custom form regions
- Word is the editor for all items except sticky notes
- Support for custom task panes
- No security prompts for external programs on standalone systems with up-to-date anti-virus protection, as reported in the Windows Trust Center
- No CDO 1.21 in the box; it's a separate download (see Collaboration Data Objects, version 1.2.1 )
- No password protection for custom forms
- No folder home page support in non-default .pst files
Office 2007 Service Pack 2 makes some additional design changes:
Inspector windows in Outlook 2007 no longer display menus and toolbars. Instead, they use the new "ribbon" user interface, which can be programmed only with an add-in. See resource links at right.
If an add-in adds commands to Inspector.CommandBars, those commands will appear on an Add-ins tab in the ribbon.
In Outlook VBA, it is still possible to execute a command using CommandBars in an Inspector window, but that technique apparently raises an error in add-ins.
Visual Studio 2008 includes a ribbon designer.
In Outlook 2007, form regions replace custom forms as the preferred method for adding or removing controls from the user interface on Inspector windows. Regions support a rich new set of Outlook-aware controls. While most implementations of form regions will be handled with an add-in, there are also some minor applications for standalone regions, particularly for making standard properties visible in the reading pane. See:
Form regions are designed to scale automatically. This means that they should always be designed on a machine with the screen resolution set to 96 dpi.
It is not possible to expand or collapse a form region programmatically. To display a form region after an item has been loaded in an Inspector window, you would need to close and reopen the item. For a code snippet, see this discussion.
Visual Studio 2008 includes a form region wizard and designer for building regions that use managed controls. You cannot, however, mix managed controls and Olk* controls on the same form, nor can you bind managed controls to Outlook properties.
Known problems with Olk* controls on form regions
The new Olk* controls for form regions should not be used on legacy custom forms. They are supported only on form regions. Using them on legacy custom forms may result in data loss.
The Olk* controls do not support a Visible property. However, that property -- along with other useful properties like Width, Top, and so on -- is implemented on MSForms.IControl, which is implemented by all of the Olk* controls. Therefore, you can cast the control to MSForms.IControl if you need to set Visible or certain other properties related to the control's UI. For more details, including a C# example, read Ryan Gregg's blog post Common Properties on Outlook Controls.
The OlkListBox control does not support multiple columns, and if you add an MS Forms 2.0 list box to the region, Outlook will automatically convert it to an OlkListBox. The solution is to add the Forms 2.0 control at runtime, in the BeforeRegionShow event handler. You will first need to set FormRegion.SuppressControlReplacement to True to prevent Outlook from converting the list box to OlkListBox.
OlkListBox controls may disappear from a region, as described in this discussion thread.
In a multiselect OlkListBox, the user must click twice on the row to deselect it.
If you implement a form region that contains an unbound control, the UserProperties collection will not be valid in the GetFormRegionStorage event when the item is first opened. This issue is a design limitation.
Other form region problems
Forms substitution is incompatible with the form regions. Specifically, if you have a replaceall form region with the derived class IPM.Note.MyRegion, use registry substitution to make that the default class, and then press the New button, Outlook will create a new message with the class IPM.Note and will ignore the form region.
Form regions also cannot be involved with the /c command-line switch.
As discussed in this discussion thread, custom properties exposed in form region controls may not be available through the UserProperties collection unless the item is open in an Inspector, but always should be accessible through the PropertyAccessor object.
Do not put editable text box or combo box controls on a form region that will be displayed in the reading pane. Any reading pane region controls should be set for read-only access. Otherwise, pressing Delete in the control will delete the item, not the text in the control.
Replying to and forwarding an email message that uses a replacement region may have unexpected behavior as described in this discussion thread. The reply and forward icons designated in the region's manifest may not be applied. Also, to reply with a custom message class, it may be necessary to open the item in an Inspector window, rather than click Reply in the Explorer. A possible workaround is to implement a published custom message form with the same message class as the form region and set its actions on the (Actions) tab to invoke the region's class.
If you add a legacy Forms 2.0 multipage or tabstrip control to a form region, it may not be possible to save the region. Do not use the multipage control at all. If you need to use the tabstrip control, add some other control to the region first, before you add the tabstrip control.
On a form region with controls arranged in rows, a large amount of extra vertical space may be inserted between rows. A solution is to turn off the automatic layout feature on the Layout tab of each control's Properties dialog.
Operations that involve the Body property should be handled in an Inspector wrapper, not in the form region wrapper. Otherwise, the add-in raises an error, as described in this discussion. The same issue affects use of Inspector.WordEditor, as described here.
If autosave is turned on, items using form regions -- even non-message items -- will save automatically in the Drafts folder.
Word as the item editor
Outlook 2007 has only one item editor, a lightweight version of Word 2007. A benefit of this change is that Inspector.WordEditor will return a Word.Document object for any type of Outlook item, except NoteItem, making it possible to use Word methods to insert text and graphics, insert a QuickPart, format text, apply a theme, and perform other item body tasks that were difficult if not impossible to perform in the past. The drawback is that Inspector.HTMLEditor no longer works at all, even on HTML-format messages, so legacy code should be checked to handle a possible error from that property. Also any legacy code dependent on Inspector.IsWordMail = True should be revisited and updated, because IsWordMail will be True for every item except NoteItem objects.
In an add-in using the Inspectors.NewInspector event, IsWordMail and WordEditor do not function as expected in the code for that event. The workaround is to use NewInspector to instantiate an Inspector object and then use that Inspector's Activate event to check IsWordMail and use WordEditor.
Outlook 2007 does not expose the context menu for a message body, something that was available in earlier versions with Word as the email editor through Document.CommandBars.
If both Outlook 2007 and Word 2007 are installed from a full Office version, the editor will have additional Word capabilities not included with the lightweight version. (This does not apply, though, if a standalone version of Outlook 2007 is installed along with Word 2007 from the Office 2007 Home and Student Edition.) However, there is no documentation on which Word.Document properties and methods do and do not work in the lightweight editor. Therefore, you may want to do any testing of item body manipulation with the Word editor on a machine that does not have the full Word 2007 application.
If you have Word macros from earlier versions that you ran in messages when Word was the e-mail editor, you will need to convert them to Outlook 2007 macros.
In earlier versions, the Document.Kind property from the Word object model could be used to distinguish Word documents from email messages using Word as the editor. Kind no longer provides that distinction in Office 2007, but Document.Signatures.Application.Name can do the trick. Thanks to Mark for sharing that solution!
In Outlook 2007, outlook: URLs -- that is, links to Outlook items and folders -- don't resolve automatically to working hyperlinks. Instead, you must explicitly insert a hyperlink. In an HTML message, you can use an <a> tag, but in a task, appointment, contact, or journal entry, you must use Word methods, as shown in this code sample, which comes from Chapter 17 in my Microsoft Outlook 2007 Programming book:
Other known problems
Microsoft has documented many issues in these articles, most notably changes to the methods that can be called from a Close event, limitations in using the new PropertyAccessor object, and some broken methods and properties:
The following additional issues have been confirmed by Outlook MVPs and reported to Microsoft:
Outlook View Control
The OVC cannot be used as a control on an Access 2007 user form.
Folder Home Pages
Folder home pages (the display of a web page associated with an Outlook folder through the WebViewURL property) are not supported in non-default .pst files, for security reasons. According to the deployment information for Office 2007, adding this registry setting should change the built-in behavior:
VALUEON NUMERIC 0
VALUEOFF NUMERIC 1
Safe Address Book wrapper
Outlook 2007 does not include or support the Safe Address Book wrapper control (Msosvabw.dll) that ships with Outlook 2002 and 2003. Code that uses CreateObject("MsSvAbw.AddrBookWrapper") will fail, including code to SharePoint 2003 site code that tries to pop up the user list. If you need to manage a SharePoint 2003 site, keep Outlook 2003 installed.
In theory, NewMailEx should fire such that each new item's EntryID is captured. In practice, it can skip items. The workaround is to also use a timer approach to check for new messages in the Inbox at some interval.
If Outlook Today (the root folder of the default information store) is the startup folder, an add-in will get no initial Explorer.Activate, .SelectionChange, or .BeforeFolderSwitch event unless the user clicks in the folder view pane.
If many folders are subscribed to the Folder.BeforeFolderMove event, that event may not fire or may work for a time and then stop firing. This issue is fixed in a post-SP2 hotfix.
When you try to use the PropertyAccessor interface on a Recipient object to determine the Recipient flags, an error is returned. This issue is fixed in SP2.
The PropertyAccessor.DeleteProperty method does not allow the deletion of certain MAPI properties that can be deleted with CDO 1.21 or Redemption.
The new StorageItem object, which is used to access hidden messages that often contain Outlook settings, comes with some limitations. It can be used to create hidden messages only in mail/post folders in an Exchange mailbox or .pst file. If you try to create a StorageItem in a non-mail folder, Outlook instead creates a visible item, not a hidden item; this issue is fixed in SP1.
StorageItem cannot create hidden messages in Exchange public folders at all, nor can it read public folder hidden messages.
Attachment object and Attachments collection
The Attachment.Delete method raises an error if you try to delete an attachment in an unsaved message that is in rich-text format. The solution is to save the message before deleting the attachment.
The Position parameter in the Attachments.Add method no longer works in rich-text format messages to place the attachment at a particular location in the item body.
If you use the Attachments.Add method, pass the file path as a variable, but the variable is a blank string, Outlook will crash. (This bug is also present in Outlook 2003 SP2.)
Problems with other methods and properties
The AddressEntry.GetFreeBusy method does not work in an Exchange 2007 environment where there is no Public Folders hierarchy; this issue is fixed in SP1.
The new UTCToLocalTime and LocalTimeToUTC methods round to the nearest minute, ignoring any seconds element.
The CalendarView.DisplayedDates property does not work. This issue is fixed in SP2.
A problem related to calling Item.Close olDiscard from an item's Close event handler is fixed in SP1; also see:
At least some of the issues that cause Outlook to crashing when Item.Close is called from a custom form's code are fixed in SP1; also see:
The new MailItem.SendUsingAccount property acts a bit oddly. It requires an Account object to set its value, but the syntax is different in VBScript and VBA. You'd expect it to take a Set keyword in both, because it is an object property. However, Set works only in VBScript. In VBA, you need to omit Set to avoid an error. Plus, SendUsingAccount returns Null unless you invoke it an event handler for either MailItem.Send or Application.ItemSend.
If you create an automatic formatting rule for a view programmatically, using the new AutoFormatRules.Add method, that rule will not persist between Outlook sessions. Therefore, you probably will want to recreate the rule for that view whenever Outlook starts.