适用于:Outlook 2013 | Outlook 2016
关注邮件附件呈现位置的客户端应用程序在邮件撰写过程中设置这些附件 的PR_RENDERING_POSITION (PidTagRenderingPosition) 属性。 不关心呈现位置的客户端会取消设置此属性。
当客户端打开带有附件的邮件时,它会尝试检索每个附件的 PR_RENDERING_POSITION 属性,以确定应在邮件文本中呈现附件的位置。 客户端可以使用下列方法之一来检索 PR_RENDERING_POSITION:
打开的附件上的 IMAPIProp::GetProps,用于检索 PR_RENDERING_POSITION 属性。
打开的邮件上的 IMessage::GetAttachmentTable 以检索其附件表。 PR_RENDERING_POSITION 是所有附件表中的必需列。 这是首选方法,因为它可提高性能。
RTF 感知消息存储可以选择是返回 PR_RENDERING_POSITION的准确值还是近似值。 由于消息存储在请求邮件 的PR_BODY 属性时会重新计算附件的 PR_RENDERING_POSITION 值,因此某些 RTF 感知消息存储仅保证客户端首先请求 PR_BODY时呈现位置的准确性。 允许 RTF 感知消息存储为客户端提供近似的呈现位置值,以提高性能。 提供近似而不是准确的呈现位置可以节省时间,并且足以满足大多数情况。
RTF 感知消息存储的近似值应基于负责创建附件的客户端指定的值。 尽管所有客户端都应设置 PR_RENDERING_POSITION,但消息存储提供程序应准备好处理其不存在的可能性。 当客户端未设置 PR_RENDERING_POSITION时,消息存储可以将其设置为 -1,以指示呈现位置不在消息文本中。 呈现位置为 -1 的附件可以在消息中的任何位置显示,具体取决于客户端。 许多客户端将这些类型的附件置于邮件顶部。
PR_RENDERING_POSITION 属性的准确性取决于消息存储是否同时保存消息的PR_BODY (PidTagBody) 和 PR_RTF_COMPRESSED (PidTagRtfCompressed) 属性,还是仅保存PR_RTF_COMPRESSED。 如果客户端生成 PR_BODY 并且消息存储将其与格式化文本一起保存,则呈现位置将准确。 但是,如果消息存储必须生成自己的 PR_BODY 版本,因为它只保存 PR_RTF_COMPRESSED,则呈现位置可能有些不准确。 这是因为客户端和消息存储提供程序生成 PR_BODY 属性的方式存在差异。
为了计算准确的 PR_RENDERING_POSITION 值,RTF 感知存储使用嵌入在格式化文本中的标记。 可以调用实用工具函数 RTFSync 来执行此计算并更新附件的呈现位置。 根据可用的状态信息量,消息存储可以将RTF_SYNC_BODY_CHANGED、RTF_SYNC_RTF_CHANGED或这两个值传递到 RTFSync。