Pocket Outlook Object Model Common Tasks

A version of this page is also available for

Windows Embedded CE 6.0 R3

4/8/2010

You can build light–weight Personal Information Manager (PIM) applications by using objects that implement interface members belonging to the Pocket Outlook Object Model (POOM) API. POOM definitions are referenced in the Pimstore.h header file, and are implemented in the Pimstore.lib file. For more information about POOM, see the Pocket Outlook Object Model Reference.

This section contains topics that present procedures with code examples that show you exactly how to use POOM to create a PIM application.

In This Section

  • Establishing a POOM Session
    Details the steps that must be performed before you can create and manipulate PIM items. Before you can create and manipulate PIM items, you must first create an instance of the IPOutlookApp and then use it to establish a POOM session, which opens a connection to the PIM database.
  • Creating a PIM Item
    Details the steps involved in creating a PIM item.

    The three PIM item types—IAppointment, ITask, and IContact—are the main object types in the Pocket Outlook Object Model, and the procedure for creating them is identical for all three.

  • Listing All PIM Items in a Folder
    Details the steps involved in listing all of the PIM items in a collection. This involves determining the number of items in the folder and then looping through the collection to iteratively retrieve a particular PIM item from the database.
  • Creating a Recurring Appointment
    Details the steps involved in creating a recurring appointment. Any Appointment becomes a Recurring Appointment when you retrieve its IRecurrencePattern object, set the recurrence values, and then save the Appointment.
  • Beginning a MAPI Session
    Before you can access a message store, you must initialize the MAPI subsystem and log onto a MAPI session. This gives you a reference to an IMAPISession interface object, which you can use to access the message store table, message stores, message folders, and messages.
  • Ending a MAPI Session
    When the user is done performing messaging tasks, there is no further need to consume valuable system resources with the messaging subsystem. At this point, it is a good idea to free resources by ending the MAPI session.
  • Connecting to a Message Store
    Before you can create and manipulate message folders and message items, you must establish a connection to a message store.
  • Creating a Message
    New messages are always created from a message store's Drafts folder. After you create a message, you can set its property values (subject, body, list of recipients, and so on) and then send the message.
  • Sending a Message
    New messages are always created and sent from a message store's Drafts folder. After you create a message, you set its property values (subject, body, list of recipients, and so on) and then post the message.
  • Registering Customized Messaging Forms
    Customized messaging forms require two separate registry entries. The first one registers the form COM server as a message class. This gives the Messaging Application the information it needs to locate the plug-in DLL and extract the read and compose forms for displaying and creating messages. The second entry specifies the message transport(s) to use.
  • Registering Customized Messaging Rules Clients
    Customized messaging rules clients require two separate registry entries. The first one registers the messaging rules client as a COM server, specifying its GUID. The second entry specifies the message transport(s) to use.