3.2 Integrating Sample Attachments and RTF

A user has just received a piece of e-mail that they would like to open and read. The following is a description of what a client might do to accomplish the user's intentions and the responses that a server might return.

The user opens the Message object by using the RopOpenMessage remote operation (ROP) ([MS-OXCROPS] section 2.2.6.1) for an e-mail message that just arrived. It was sent with the message ID and folder ID described in the following table.

The body properties are retrieved to determine which body format is appropriate to load, as described in [MS-OXBBODY]. The client sends a RopGetPropertiesSpecific ROP request ([MS-OXCROPS] section 2.2.8.3) and the server responds with the information described in the following table.

Based on the server responses, the proper body to load is the value of the PidTagRtfCompressed property.

The PidTagRtfCompressed property is stored in a packed format; by using the RTF Compression Algorithm, as described in [MS-OXRTFCP], the content is decoded and the raw RTF is as follows:

 {\rtf1\ANSI\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}}<CR><LF>{\*\generator<SP>Riched20<SP>5.50.99.2050;}\viewkind4\uc1\pard\f0\fs20<SP>This<SP>is<SP>a<SP>test<SP>e-mail.\par<CR><LF>\objattph\'20\par<CR><LF>\par{\*\optional<SP>with<SP>an<SP>optional<SP>line\par}<CR><LF>Lets<SP>have<SP>another<SP>attachment\par<CR><LF>\objattph\'20\par<CR><LF>\par<CR><LF>Adding<SP>a<SP>picture\par<CR><LF>\objattph\'20\par<CR><LF>}

This algorithm is then used to determine whether the RTF is encapsulated by examining the RTF tokens before the font table destination. Because the FROMHTML and FROMTEXT control words are not found in the RTF header, the contents are not encapsulated.

As the body is loaded and the RTF reader parses the RTF, the render position of each \objattph token is calculated and stored in an array similar to that which is described in the following table.

Note There is an optional destination (\optional) that is not understood by the RTF reader. This affects the rendered token locations, as the contents "with an optional line < CRLF >" are not rendered.

When the body parsing is complete and the existence of placeholder tokens is recorded, the attachments from the message are loaded.

The following ROP requests are transmitted to the server:

• The RopGetAttachmentTable ROP ([MS-OXCROPS] section 2.2.6.17).

• The RopSetColumns ROP ([MS-OXCROPS] section 2.2.5.1), which requests the PidTagAttachNumber ([MS-OXCMSG] section 2.2.2.6), PidTagAttachMethod ([MS-OXCMSG] section 2.2.2.9), PidTagRenderingPosition ([MS-OXCMSG] section 2.2.2.16), PidTagAttachLongFilename  ([MS-OXCMSG] section 2.2.2.10), and PidTagAttachmentHidden ([MS-OXCMSG] section 2.2.2.24) properties.

• The RopQueryRows ROP ([MS-OXCROPS] section 2.2.5.4).

The response buffer from the RopQueryRows ROP contains three rows, as described in the following three tables.

Row 1

Row 2

Row 3

Because the attachments are already ordered correctly by rendering position, they do not need to be reordered.

Because the attachment list is three entries long, and the previously constructed position array is also three entries long, the insertion positions come from the position array. This results in replacing the second and third attachments at different positions than those set in the value of the PidTagRenderingPosition property. Specifically, the second attachment ("helloworld.doc") will replace position 54, not 76, and the third attachment will replace position 74, not 100.

Looping over the stored objattph positions in the position array, each attachment is prepared for insertion.

The first attachment ("helloworld.txt") replaces rendered character position 22. The second attachment ("helloworld.doc") replaces the rendered character position 54. Finally, the last attachment ("PBrush") replaces the rendered character position 74.

Because there are no additional attachments, the integration is complete.