Platform SDK: MAPI |
Structured messages can be sent and read between programs, or between programs and users. By using MAPI properties to structure message content, you avoid writing code to parse message text or a binary attachment.
Logically, person-to-person applications, machine-to-person applications, and applications that post to public forums should be designated IPM, while person-to-machine and machine-to-machine applications are IPC message classes. The only real difference is that IPM messages in a message store are visible to messaging clients, while IPC messages usually are not. Anything that requires a person to respond must use an IPM message class. Applications involving a more complex pattern including people and machines often involve a mix of IPM and IPC messages.
One difference between IPM and IPC applications is that machines are much less tolerant of variations in message format than people are. Compatibility with messaging clients that can view only message text is often required for IPM applications, but IPC applications typically use MAPI properties to structure information in their messages and require MAPI everywhere. Nevertheless, for machine-to-person applications it may be necessary to duplicate some or all of the properties in the message text for compatibility with messaging clients that can view only message text.
|
To open the receive folder:
1. Call the IMsgStore::GetReceiveFolder method.
2. Pass the entry identifier returned to the IMsgStore::OpenEntry method. |
To open the Outbox (send folder) for IPM only:
1. Call the message store's IMAPIProp::GetProps method to retrieve the PR_IPM_OUTBOX_ENTRYID property.
2. Pass the entry identifier to the IMsgStore::OpenEntry method. |
Remember to handle the disposition of submitted messages. IPM message classes should honor common IPM client options for disposition of sent messages and the message store's PR_IPM_SENTMAIL_ENTRYID property.
1. Open the contents table on the receive folder, using the IMAPIContainer::GetContentsTable method.
2. Register for notification of new mail, using the IMsgStore::Advise method, the fnevNewMail event, and a null entry identifier. Do this before retrieving any messages to avoid a race condition that would result in missing messages. 3. Create a property restriction to match PR_MESSAGE_CLASS with your message class and apply it to the contents table by calling IMAPITable::Restrict. Consider also limiting your contents table view to unread messages by creating a bitmask restriction with the MSGFLAG_UNREAD flag as the mask for the PR_MESSAGE_FLAGS property. See About Restrictions. 4. Retrieve all the messages from the table, using the HrQueryAllRows function or the IMAPITable::QueryRows method, and process them. 5. Rely on new mail notifications to advise you of further incoming messages. Your notification handler should check the lpszMessageClass member of the NEWMAIL_NOTIFICATION structure and ignore any messages that are not of your class. |
See the following topic: