This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Contains a bitmask of flags that client applications should query to determine the characteristics of a message store.
This property discloses the capabilities of a message store to client applications planning to send it a message. The flags can facilitate decisions by a client or another store, such as whether to send PR_BODY (PidTagBody) or only PR_RTF_COMPRESSED (PidTagRtfCompressed). A client should never set PR_STORE_SUPPORT_MASK; an attempt returns MAPI_E_COMPUTED.
One or more of the following flags can be set for the PR_STORE_SUPPORT_MASK bitmask:
(131072, 0x00020000) The message store supports properties containing ANSI (8-bit) characters.
(32, 0x00000020) The message store supports attachments (OLE or non-OLE) to messages.
(1024, 0x00000400) The message store supports categorized views of tables.
(16, 0x00000010) The message store supports creation of new messages.
(1, 0x00000001) Entry identifiers for the objects in the message store are unique, that is, never reused during the life of the store.
(65536, 0x00010000) The message store supports HTML messages, stored in the PR_BODY_HTML (PidTagBodyHtml) property. Note that STORE_HTML_OK is not defined in versions of MAPIDEFS.H that are included with Microsoft Exchange 2000 Server and earlier. If your development environment uses a MAPIDEFS.H file that does not include STORE_HTML_OK, use the value 0x00010000 instead.
(2097152, 0x00200000) In a wrapped PST store, indicates that when a new message arrives at the store, the store does rules and spam filter processing on the message separately. The store calls IMAPISupport::Notify, setting fnevNewMail in the NOTIFICATION structure that is passed as a parameter, and then passes the details of the new message to the listening client. Subsequently, when the listening client receives the notification, it does not process rules on the message.
(524288, 0x00080000) This flag is reserved and should not be used.
(8, 0x00000008) The message store supports modification of its existing messages.
(512, 0x00000200) The message store supports multivalued properties, guarantees the stability of value order in a multivalued property throughout a save operation, and supports instantiation of multivalued properties in tables.
(256, 0x00000100) The message store supports notifications.
(64, 0x00000040) The message store supports OLE attachments. The OLE data is accessible through an IStorage interface, such as that available through the PR_ATTACH_DATA_OBJ (PidTagAttachDataObject) property.
(16384, 0x00004000) The folders in this store are public (multi-user), not private (possibly multi-instance but not multi-user).
(8388608, 0x00800000) The MAPI Protocol Handler will not crawl the store, and the store is responsible to push any changes through notifications to the indexer to have messages indexed.
(2, 0x00000002) All interfaces for the message store have a read-only access level.
(4096, 0x00001000) The message store supports restrictions.
(2048, 0x00000800) The message store supports Rich Text Format (RTF) messages, usually compressed, and the store itself keeps PR_BODY and PR_RTF_COMPRESSED synchronized.
(4, 0x00000004) The message store supports search-results folders.
(8192, 0x00002000) The message store supports sorting views of tables.
(128, 0x00000080) The message store supports marking a message for submission.
(32768, 0x00008000) The message store supports storage of RTF messages in uncompressed form. An uncompressed RTF stream is identified by the value dwMagicUncompressedRTF in the stream header. The dwMagicUncompressedRTF value is defined in the RTFLIB.H file.
(262144, 0x00040000) The message store supports properties containing Unicode characters.
An RTF version of a message can always be stored, even if the message store is non-RTF-aware. If the STORE_RTF_OK bit is not set for a particular store, a client maintaining RTF versions must itself call the RTFSync function to keep the PR_BODY and PR_RTF_COMPRESSED versions synchronized for text content. RTF is always stored in PR_RTF_COMPRESSED, whether it is actually compressed or not.