Excellent news! We just published the Microsoft Office Outlook 2007 Auxiliary Reference:
(This is a greatly enhanced version of the earlier Microsoft Office Outlook 2003 Integration API)
This reference was a huge collaborative effort, of which I was only a small part. Parts of this reference are based on my blog entries, but large sections of it were written by others. For instance, we have a new sample address book provider, written by Xiaoming Yin. And this reference wouldn't have happened at all without the tireless efforts of Angela Chu-Hatoun and Allison Bokone, who had the jobs of taking all this information from disparate sources and hammering on it until we had something we could publish. And then there were the PMs and developers who contributed, too many to name here. It was a race to the finish. The last topic added was actually written yesterday morning!
I wanted to point out a couple things that we know we didn't have time to finish:
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0708&L=MAPI-L&P=R14899 http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0709&L=MAPI-L&D=0&P=13248 http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0709&L=MAPI-L&P=R1623 http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0709&L=MAPI-L&D=0&P=15085
I'll post when these issues are corrected.
As we did with the Integration API before, we'll be using my blog to post any errata. You can contact me directly or through comments if you discover any problems with the reference. Enjoy!
[This is now documented here: http://msdn2.microsoft.com/en-us/library/bb821131.aspx]
This is a topic from an upcoming refresh to the Outlook Integration API documentation. Since some folks had expressed interest in getting this topic now, development allowed me to blog it. Enjoy!
About Conflict Resolution for Custom Item Types
This topic describes how you can specify how conflicts are resolved for custom item types that you create in Microsoft Office Outlook.
Conflict Resolution for Standard Outlook Item Types
In Outlook, conflicts occur when two or more copies of the same item have been modified independently of each other. Outlook detects conflicts during synchronization. For example, you update a meeting request online on Outlook Web Access and then you update the same meeting request on Outlook when you work offline. When Outlook goes online again and synchronizes the data between the client computer and the server, it detects that there are two different copies of the same meeting request.
Versions of Outlook before Outlook 2003
In versions of Outlook before Outlook 2003, when Outlook synchronizes data, it does not consider properties specific to an item type. When Outlook detects conflicts, Outlook presents the conflicting copies of the item and the user decides which copy to keep.
Outlook 2003 and Outlook 2007
In Outlook 2003 and Outlook 2007, when Outlook synchronizes items that belong to a standard Outlook item type, it takes into consideration the properties that are specific to that item type to detect possible conflicts. Outlook tries to resolve conflicts and stores the resultant copy in the appropriate folder without requesting user intervention. In cases where Outlook considers that there is a possibility that the resultant copy may not contain all essential data, Outlook stores the conflicting copies in the Conflicts folder, under the Sync Issues folder. (Note that Sync Issues and its subfolders are hidden until you click Folder List on the Go menu.) In such cases, users can choose to go to the Conflicts folder to verify which items were in conflict and whether to use a copy in the Conflicts folder to replace the copy that Outlook decided to retain.
Conflict Resolution for Custom Item Types
Item Types and Message Classes
All items in Outlook are associated with a message class. For example, by default, a mail item is associated with the message class IPM.Note. The message class is primarily used to identify the form that should be used to display the item in Outlook. Outlook supports a list of message classes that are mapped to the types of items built in to Outlook. For more information about message classes, see Item Types and Message Classes.
Users can create custom item types, assign custom message classes to the custom item types, and have Outlook use a custom form to display the custom item types. For example, you may want Outlook to display a custom business contact form for your business contacts. To do that, you can create a custom message class IPM.Contact.Business, create a custom form for this message class, and assign business contacts with this message class.
Registering Conflict Resolution Scheme for Custom Item Types
When you create a custom item type, other than the custom message class and custom form, you should also consider how you would like Outlook to handle conflicts between copies of an item of this item type. By default, because custom item types may define custom fields in the custom form, and may have custom properties and custom code, Outlook employs a resolution scheme common to all items, does not consider properties that are specific to an item type, and presents conflicting copies for the user to make a decision. If you want Outlook to consider item-specific properties and attempt to resolve the conflict with minimal user intervention, you must specify that through a setting in the Windows registry. This can be achieved by either applying a Group Policy setting to the a local computer that sets the following registry key:
Or by directly modifying the following user registry key:
Setting the conflict resolution through Group Policy takes precedence over directly modifying the user registry key. The location of the key in the registry is dependent on the version of Outlook. You specify the name of the custom message class as a value under this key. Specify the type of the value as DWORD, and the data of the value as one of the following possible values, depending on the resolution scheme you choose:
If you specify one of the item-specific resolution schemes (data2 through 8), Outlook will try to resolve conflicts in item-specific fields (for example, Start and End fields of an appointment item) automatically without user intervention. If Outlook considers that the resolution may result in loss of essential data, Outlook will retain conflicting copies in the Conflicts folder and users can choose to go to the Conflicts folder to manually re-resolve these items and override the automatic resolution.
Using the same business contacts example above, if you want to specify the contact item-specific resolution scheme for the custom message class IPM.Contact.Business, you can add it as a DWORD value under [HKCU]\Software\Microsoft\Office\12.0\Outlook\Options\ConflictMsgCls, and specify 5 as the data.
In Outlook 2007 Service Pack 1, Outlook always uses a resolution scheme specific to appointment items for custom message classes that are based on the appointment message class (that is, any custom message class that is preceded by IPM.Appointment, for example, IPM.Appointment.Personal).
This is a question for those of you out there who still have Exchange Client Extensions.
Aside from budget concerns and legacy support, what blocks you from re-implementing your extension as an Outlook Add-In? Specifically, I'm looking for events and capabilites that would have to be added to the Outlook Object Model to allow you to migrate your code.
For example, ECEs have an OnRead event that happens before Outlook reads from a message. This allows the extension to modify the message first. The OOM's Read event happens after Outlook reads from the message, so it's too late. You would need some sort of BeforeRead event to match the ECE.
Can you come up with more? I've got a list I put together here, but I want to see what you folks have actually run up against, so I'm most interested in real world examples drawn from your own code. Thanks!
Welcome viewers from Patrick and Randy's blog! I've seen a few comments that indicate support for legacy clients is a major concern. We definitely understand that and it's on our list. But what we're looking for here is things that you're doing with ECEs right now that you cannot do with Add-Ins. To put it another way - if ECEs suddenly vanished and you had to implement your code in an Add-In, what missing features or capabilities would be showstoppers?