Known issues in Outlook 2010 when you use the object model
Original KB number: 2265515
This article describes the known issues that may occur when you use the Microsoft Outlook 2010 object model.
Outlook.Application object from an elevated process
You cannot automate Outlook by using a process that is running with elevated permissions in Windows Vista, in Windows 7, or in any other operating system that allows for running processes with elevated permissions. This is an underlying limitation of the COM. Both Outlook and custom programs that automate Outlook must be running at the same integrity level.
The BeforeItemMove and BeforeFolderMove events don't occur
There are multiple scenarios where the
BeforeFolderMove events don't occur. Known scenarios include deleting appointments from the To-Do bar, deleting meetings from the calendar and To-Do bar, implementing the events on nondefault folders, and deleting items by using the Ignore Conversation command. These problems were fixed in the December 2010 Cumulative Update for Outlook 2010.
GetProperty method fails in online mode
If you use Microsoft Exchange 2010 in online mode, and you use the
GetProperty method to retrieve a property from an unsaved item, the method may fail. This is because of a change in the way that Exchange 2010 handles named properties. Outlook 2007 is also affected. The current workarounds include the following:
- Use Outlook in cached mode.
- Make sure that the item is in a saved state before you call the
Inspector window may not close correctly
If you implement the
GetVisibleCallback function in Microsoft Visual Studio Tools for Microsoft Office (VSTO), the user may be unable to close an inspector window correctly. This issue was fixed in the February 2011 Cumulative Update for Outlook 2010.
BeforeCheckNames event occurs at a different time than it occurs in Outlook 2007
In Outlook 2010, the BeforeCheckNames event occurs after recipients are resolved instead of before they are resolved. This means that canceling the event has no effect. This problem was corrected in the Outlook 2010 February 2011 Cumulative Update.
Views object model may not correspond to actual view in the user interface
There are scenarios in which, if you programmatically change views or retrieve view settings, the settings in the object model may not correspond to the actual view settings that Outlook displays in the user interface. Improvements were made in the Outlook 2010 February 2011 Cumulative Update to resolve this problem.
Attachments are not maintained correctly when you use the Insert Item window
If you use the Outlook object model to add and remove attachments, you may have an extra attachment if a user inserts an item attachment by using the Insert Item command. This is because of a bug in the way that the dialog box treats all attachments as suspect even if they are not suspect. Therefore, extra attachments are saved together with the message. This issue was fixed in the February 2010 Cumulative Update for Outlook 2010.
Cannot insert item attachments by using a POP/IMAP account
If you use the
Attachments.Add method to add Outlook item attachments by using a POP/IMAP account, the call fails. This issue was fixed in the December 2010 Cumulative Update for Outlook 2010.
MailItem.Recipients.ResolveAll function removes recipients from the To field
If the user adds an unresolved recipient to a message in compose mode, and then the
Recipients.ResolveAll method is called for that item, the recipients are removed. There are no plans to change this behavior.
GetAssociatedAppointment method fails for a meeting request in the Sent Items folder
If you try to retrieve an appointment from a meeting request in the Sent Items folder, the call fails. This issue was fixed in the February 2011 Cumulative Update for Outlook 2010.
Appointment data may not be updated if an inspector window is open
Because of internal changes in the way that Outlook 2010 handles and caches appointments, the object model may not provide up-to-date information about exceptions to appointments if the corresponding appointment is open in an inspector window. This behavior occurs even if you de-reference and re-retrieve the item from the store. To work around this problem, make sure that the appointment window is closed. There are no plans to change this behavior.
NavigationFolder.Folder generates error on shared folder
If you try to get the Folder object from a
NavigationFolder object, you may receive an "Operation failed" error message. This problem occurs with shared calendar folder features that are new in Outlook 2010. Retrieving the
NavigationFolder.Folder object before Outlook has initialized it causes this problem to occur. This initialization doesn't take place by default. To work around this problem, first reference the default calendar folder and call the
GetExplorer method. This indirectly causes Outlook to initialize the shared calendars. The following Outlook VBA code example illustrates this issue and the workaround:
Sub GetCalendars() ' Work around Set oCalFolder = Session.GetDefaultFolder(olFolderCalendar) Set oCalExp = oCalFolder.GetExplorer Dim oModules As Outlook.CalendarModule Dim oMyCalendarGroup As Outlook.NavigationGroup Dim oPeopleNavGroup As Outlook.NavigationGroup Set oModules = ActiveExplorer.NavigationPane.Modules.GetNavigationModule(OlNavigationModuleType.olModuleCalendar) Set oMyCalendarGroup = oModules.NavigationGroups.GetDefaultNavigationGroup(OlGroupType.olMyFoldersGroup) Set oPeopleNavGroup = oModules.NavigationGroups.GetDefaultNavigationGroup(OlGroupType.olPeopleFoldersGroup) GetNavFolders oMyCalendarGroup GetNavFolders oPeopleNavGroup End Sub Private Sub GetNavFolders(ByVal obj As Outlook.NavigationGroup) Set oNavFolders = obj.NavigationFolders Dim oNavFolder As Outlook.NavigationFolder For Each oNavFolder In oNavFolders Debug.Print oNavFolder.DisplayName & "==>" & oNavFolder.Folder ' <-- this errors Next End Sub