Known issues in Outlook 2010 when you use the object model
Original KB number: 2265515
Summary
This article describes the known issues that may occur when you use the Microsoft Outlook 2010 object model.
Cannot create 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 BeforeItemMove
and 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
GetProperty
method.
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.
The 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