Differences Between the Pocket Outlook Object Model and the Outlook Object Model
The following topics discuss the principal differences between the Pocket Outlook Object Model and the Outlook object model.
- Cancel Method
In the Outlook Object Model, to send a meeting-request cancellation, set the MeetingStatus property to OlMeetingStatus::olMeetingCanceled. In Pocket Outlook Object Model (POOM), IAppointment::get_MeetingStatus is read-only, so IAppointment::Cancel was added to send a meeting-request cancellation. To delete a meeting from the calendar, you can call IAppointment::Delete.
- Infrared Support
With the OlDefaultFolders type olFolderInfrared, you can send a collection of any type of Microsoft Office Outlook items over the Infrared port. You should call IPOutlookApp::GetDefaultFolder first, then you can call the following methods on this IFolder object.
- No Events
Item events are not supported in the Pocket Outlook Object Model (POOM).
- No NameSpace Object
Unlike the desktop version of the Outlook object model, there is no NameSpace in Pocket Outlook Object Model (POOM). The required logon functionality is merged with the POOM IPOutlookApp object.
- Outlook Compatibility
The IPOutlookApp::get_OutlookCompatible method provides a way for independent software vendors to find out if the Windows Embedded CE-based device has a device partnership with a desktop computer that is running Microsoft Schedule+ for Windows 95, or Microsoft Outlook. The main reason is that there is a difference in the behavior of Task items. When your device has a partnership with a desktop computer that is running Microsoft Schedule+, Tasks with a Start Date of None must also have a Due Date of NONE. Recurrences of the Tasks are computed with respect to the Due Date. When your device has a partnership with a desktop computer that is running Outlook, recurrences of Tasks are computed only with respect to the Start Date.
- Recipients Define Meeting Requests
In the Outlook Object Model, you set an Appointment's OlMeetingStatus property to mark it as a Meeting Request. As a result, you can create Appointment items that have a Recipient List but are not Meeting Requests. This is not possible on Windows Embedded CE–based devices.
In the Pocket Outlook Object Model (POOM), an Appointment is a Meeting Request if it has a IRecipients collection. The IAppointment::get_MeetingStatus method returns the OlMeetingStatus enumeration values of either olNonMeeting or olMeeting.
The IRecipient::get_Address method returns a read-only version of the recipient's e-mail address, and the IRecipient::put_Address method accesses a writable version. In the desktop version of Outlook, the same property returns a read-only version. There is no writable version because there is no IPOlRecipient::Resolve method in the desktop version of Outlook (which matches a Recipient's first and last names with Contact names in the data store).
- Reminder Methods
The Windows Embedded CE-based device defines several notification options that the desktop does not define. Flashing LED and Vibration are examples of notification options. To handle this, the ReminderPlaySound property was replaced with the more comprehensive OlReminderOptions property method (IAppointment::get_ReminderOptions, IAppointment::put_ReminderOptions, ITask::get_ReminderOptions, ITask::put_ReminderOptions).
- No Inspector or Explorer Object
Users can view an item only through its Display method, which is limited compared to the desktop. You can display only an unmodified item. To display a modified item, you have to release it, and then reload it.
- OID Instead of EntryID
In the Outlook , items are uniquely identified by their ENTRYID property. In the Pocket Outlook Object Model (POOM), items are uniquely identified by their Object Identifier (OID).
The main IPOutlookApp object supports the IPOutlookApp::GetItemFromOid method, retrieves the item given its OID.
You must not cache the OID from an item as you would cache an Entry Identifier. OIDs can change if the device is backed up and restored. If you must cache OIDs, you should have a daemon program that runs after a restore to reset these values.
Windows® phones include a messaging sub-system for sending, receiving, storing, and manipulating e-mail and Short-Message Service (SMS) text messages. The Microsoft messaging client application, Messaging (formerly Inbox), provides the user interface for creating and reading messages, and for accessing and manipulating the message items in local and remote message stores. The Windows Mobile version of the Messaging API (MAPI) is a COM-based library that provides programmatic access to this functionality. It mirrors the Microsoft Exchange Server version of MAPI, but has a smaller scope of functionality to accommodate the practical constraints of mobile devices.