Redigera

Dela via

Attachment tables

  • Artikel

Applies to: Outlook 2013 | Outlook 2016

An attachment table contains information about all of the attachment objects that are associated with a submitted message or a message under composition.

Only attachments that have been saved through a call to the message's IMAPIProp::SaveChanges method are included in the table. Attachment tables are implemented by message store providers and used by client applications and transport providers.

An attachment table can be accessed by calling either of the following:

Attachment tables are dynamic.

Message store providers are not required to support sorting on their attachment tables. If sorting is not supported, the table must be presented in order by rendering position — the PR_RENDERING_POSITION (PidTagRenderingPosition) property.

Message store providers are also not required to support restrictions on their attachment tables. Providers that do not support restrictions return MAPI_E_NO_SUPPORT from their implementations of IMAPITable::Restrict and IMAPITable::FindRow.

Attachment tables can be small; there are only four columns in the required column set:

PR_ATTACH_NUM is nontransmittable and contains a value for uniquely identifying an attachment within a message. This property is often used as an index into the rows of the table. PR_ATTACH_NUM has a short lifespan; it is only valid while the message containing the attachment is open. Its value is guaranteed to remain constant as long as the attachment table is open.

PR_INSTANCE_KEY is required in nearly every table. It is used to uniquely identify a particular row.

PR_RECORD_KEY is commonly used to uniquely identify an object for comparison purposes. Unlike PR_ATTACH_NUM, PR_RECORD_KEY has the same scope as a long-term entry identifier; it remains available and valid even after the message is closed and reopened. For more information about the use of record keys in MAPI, see MAPI Record and Search Keys.

PR_RENDERING_POSITION indicates how an attachment should be displayed in a rich text message. It can be set to an offset in characters, with the first character of the message content as stored in the PR_BODY (PidTagBody) property being offset 0, or to -1 (0xFFFFFFFF), indicating that the attachment should not be rendered within the message text at all. Not setting PR_RENDERING_POSITION is also an option.

When an attachment table is sorted by rendering position, the message store provider treats it as a signed value (PT_LONG). Therefore, attachments with rendering positions of -1 are sorted before attachments with rendering positions that reflect valid offsets.

For more information about rendering an attachment in a plain text message, see Rendering an Attachment in Plain Text.

For information about rendering an attachment in formatted text such as Rich Text Format (RTF), see Rendering an Attachment in RTF Text.

Some of the properties message store providers commonly include in an attachment table because they are easy to compute or retrieve are:

Property ...
PR_ATTACH_ENCODING (PidTagAttachEncoding)
PR_ATTACH_EXTENSION (PidTagAttachExtension)
PR_ATTACH_FILENAME (PidTagAttachFilename)
PR_ATTACH_LONG_FILENAME (PidTagAttachLongFilename)
PR_ATTACH_PATHNAME (PidTagAttachPathname)
PR_ATTACH_LONG_PATHNAME (PidTagAttachLongPathname)
PR_ATTACH_METHOD (PidTagAttachMethod)
PR_ATTACH_TAG (PidTagAttachTag)
PR_CREATION_TIME (PidTagCreationTime)
PR_ATTACH_TRANSPORT_NAME (PidTagAttachTransportName)
PR_DISPLAY_NAME (PidTagDisplayName)
PR_LAST_MODIFICATION_TIME (PidTagLastModificationTime)

See also