|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
PidTagSubjectPrefix Canonical Property
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 subject prefix that typically indicates some action on a message, such as "FW: " for forwarding.
PR_SUBJECT_PREFIX, PR_SUBJECT_PREFIX_A, PR_SUBJECT_PREFIX_W
These properties are recommended on all message objects.
The subject prefix consists of one or more alphanumeric characters, followed by a colon and a space (which are part of the prefix). It must not contain any nonalphanumeric characters before the colon. Absence of a prefix can be represented by an empty string or by this property not being set.
If these properties are set explicitly, the string can be of any length and use any alphanumeric characters, but it must match a substring at the beginning of the PR_SUBJECT (PidTagSubject) property. If these properties are not set by the sender and must be computed, their contents are more restricted. The rule for computing the prefix is that PR_SUBJECT must begin with one, two, or three letters (alphabetic only) followed by a colon and a space. If such a substring is found at the beginning of PR_SUBJECT, it then becomes the string for these properties (and also stays at the beginning of PR_SUBJECT). Otherwise, these properties remain unset.
These properties and PR_NORMALIZED_SUBJECT (PidTagNormalizedSubject) should be computed as part of the IMAPIProp::SaveChanges implementation. A client should not prompt IMAPIProp::GetProps for their values until they have been committed by an IMAPIProp::SaveChanges call.
The subject properties are typically small strings of fewer than 256 characters, and a message store provider is not obligated to support the OLE IStream interface on them. A client should always attempt access through the IMAPIProp interface first, and resort to IStream only if MAPI_E_NOT_ENOUGH_MEMORY is returned.