Sending a Reply

Client applications typically support two types of replies: one that is sent only to the sender of the original message and one that is sent to all other recipients included in the recipient list of the original message in addition to the sender. This second type of reply is commonly referred to as a reply all message.

To send a reply of either type, you implement some of the same tasks that you would when you send an original message. For example, you open the default message store and the outgoing message folder, typically the Outbox, and call the outgoing folder's IMAPIFolder::CreateMessage method to create the reply. Also, you open the folder that holds the original message, typically the Inbox. For information about opening different folders, see Opening a Folder.

The main difference between creating a reply and creating an original message is that with a reply, most of the properties are either based on or copied directly from properties of the original message. Attachments — a message's PR_MESSAGE_ATTACHMENTS property — are specifically excluded. The recipient list for a reply all message is created from the original message's list with the recipient represented by the PR_RECEIVED_BY_SEARCH_KEY property and all blind carbon copy recipients removed. The PR_RECEIVED_BY_SEARCH_KEY property represents the current user.

    To send a reply

1. Open the default message store. See Opening the Default Message Store.
2. Open the Outbox folder. See Opening a Folder.
3. Call the Outbox's IMAPIFolder::CreateMessage method to create the reply.
4. Call the original message's IMAPIProp::CopyTo method to copy the following properties to the reply message:
   • PR_BODY or PR_RTF_COMPRESSED, depending on whether or not you support Rich Text Format.
   • PR_MESSAGE_RECIPIENTS, if the reply will go to the entire recipient list.
   • PR_NORMALIZED_SUBJECT.
5. Do not include the following properties in your call to IMAPIProp::CopyTo:

6. Add separator text to whichever message body property you support — PR_BODY or PR_RTF_COMPRESSED.
7. Call ScCreateConversationIndex, passing in the value of the original message's PR_CONVERSATION_INDEX property.
8. Set a prefix for the reply. If you are using the standard "RE:", concatenate these characters onto the beginning of PR_NORMALIZED_SUBJECT and set PR_SUBJECT to this new string. Do not set PR_SUBJECT_PREFIX. If you are using a nonstandard prefix, such as a string longer than three characters, store it in PR_SUBJECT_PREFIX.
9. Set the PR_SENT_REPRESENTING properties to the corresponding values in the PR_RCVD_REPRESENTING properties.
10. Set each of the entries in PR_REPLY_RECIPIENT_ENTRIES and PR_REPLY_RECIPIENT_NAMES to the entry identifier and display name of a primary recipient — a recipient whose type is MAPI_TO.

    Keep these properties synchronized. That is, PR_REPLY_RECIPIENT_ENTRIES and PR_REPLY_RECIPIENT_NAMES must contain the same number of entries, and an entry at a particular position in one of the properties must correspond to an entry at the same position in the other property.

11. If the reply is being sent only to the sender of the original message, create a single entry recipient list with the recipient represented by the original message's PR_SENT_REPRESENTING property. For more information about creating a recipient list, see Creating a Recipient List.
12. If the reply is a reply all, create a recipient list as follows:
    1. Call the original message's IMessage::GetRecipientTable method to access its recipient table.
    2. Call HrQueryAllRows to retrieve all of the rows in the table. Determine if each row represents a primary or carbon copy recipient and should remain in the list or if it represents a blind carbon copy recipient or the user and should be removed from the list.
    3. Differentiate between recipient types by looking at the PR_RECIPIENT_TYPE column. This column will be set to MAPI_TO for primary recipients, MAPI_CC for carbon copy recipients, and MAPI_BCC for blind carbon copy recipients.
    4. Compare the PR_SEARCH_KEY column with the PR_RECEIVED_BY_SEARCH_KEY property of the original message to determine if the row represents the user.
    5. Remove unwanted rows from the recipient list by calling MAPIFreeBuffer to free the memory associated with the corresponding entries in the recipient table's SRowSet structure. Set all of the values in the property value array to zero, all of the cValues members to zero, and all of the lpProps members in each SRow structure in the SRowSet to NULL.
    6. Add the sender to the recipient list, as represented by the original message's PR_SENT_REPRESENTING_NAME and PR_SENT_REPRESENTING_ENTRYID properties. Check that the sender is not duplicated in the list.
    7. Call the reply message's IMessage::ModifyRecipients method, setting the ulFlags parameter to zero, to create a new recipient list for the reply or forwarded message based on the list from the original message.
13. Call the reply's IMAPIProp::SaveChanges method to save the message or IMessage::SubmitMessage to save and send it.

Note Before calling IMessage::ModifyRecipients to store changes in the recipient list, you can allow users to make modifications through the message form. Users can add to the list or remove particular members. Allowing users to make changes to a recipient list is an optional client feature.