ch4.htm

MAPI__SAPI__TAPI

    <td WIDTH="75">Boolean</td>
    <td WIDTH="349">Flag that indicates the item has been sent to the recipient. </td>
  </tr>
  <tr>
    <td WIDTH="166"><tt><font FACE="Courier">Sent</font></tt></td>
    <td WIDTH="75">Boolean</td>
    <td WIDTH="349">Read/write.</td>
  </tr>
  <tr>
    <td WIDTH="166"><tt><font FACE="Courier">Signed</font></tt> </td>
    <td WIDTH="75">Boolean</td>
    <td WIDTH="349">Read/write.</td>
  </tr>
  <tr>
    <td WIDTH="166"><tt><font FACE="Courier">Type</font></tt></td>
    <td WIDTH="75">String</td>
    <td WIDTH="349">Value that identifies this message as one of a class of messages. 
    Currently, Microsoft Mail systems recognize the IPM (Interpersonal Message) type for 
    sending messages read by persons. Microsoft has defined the Ipc (Interprocess 
    Communication) type for use between program processes. Other types can be defined and used 
    by other programs. </td>
  </tr>
  <tr>
    <td WIDTH="166"><tt><font FACE="Courier">Unread</font></tt> </td>
    <td WIDTH="75">Boolean</td>
    <td WIDTH="349">Flag that indicates whether the message has been received and/or read by 
    the recipient. </td>
  </tr>
</table>
</center></div>

<h4>The Message Body</h4>

<p>The message body contains the text data sent to the recipient from the sender. For most 
systems, this is a pure ASCII text message. However, some service providers can handle 
rich-text format message bodies, which allows for additional information such as font, 
color, and format codes to be included in the message body (see Figure 4.2). </p>

<p><a HREF="f4-2.gif"><b>Figure 4.2 :</b> <i>Using Microsoft Exchange to send a rich-text 
message.</i></a> </p>

<p>The availability and support of rich-text message bodies vary between service 
providers. Some service providers allow you to create rich-text message bodies but 
translate the information into simple ASCII upon delivery. For example, Microsoft Exchange 
allows users to build rich-text message bodies but translates that message into simple 
ASCII text when using the SMTP service provider. All messages received by the Microsoft 
Mail system are converted into simple text as well. This behavior ensures that the message 
will be delivered but may result in surprise or even unreadable material at the 
recipient's end (see Figure 4.3). </p>

<p><a HREF="f4-3.gif"><b>Figure 4.3 : </b><i>Receiving a rich-text message that has been 
changed to simple ASCII.</i></a> </p>

<p>Other transport providers may transmit the rich-text and allow the receiving message 
provider to handle the translation to simple ASCII, if needed. This option allows for the 
most flexibility but can result in undeliverable messages. For example, Microsoft Exchange 
users have the option of sending rich-text messages through the CompuServe message 
transport. The CompuServe transport supports rich-text messages. Rich-text messages sent 
from one Windows Messaging Client to another by way of the CompuServe transport retain 
their original layout and look. However, recipients using something other than Microsoft 
Exchange may see something different. For example, the WinCIM client provided by 
CompuServe treats rich-text messages as binary attachments to a simple ASCII text message. 
WinCIM clients would receive the message shown in Figure 4.2 as an attachment to view with 
Microsoft Word or some other viewer. </p>

<p>If, however, the CompuServe recipient is defined as an Internet user through the 
CompuServe address (for example, [e-mail]), the CompuServe message 
transport reports the message as undeliverable when it is discovered that the message body 
contains anything other than simple ASCII text (see Figure 4.4). </p>

<p><a HREF="f4-4.gif"><b>Figure 4.4 : </b><i>Reporting an undeliverable rich-text message.</i></a> 
</p>

<h4>Message Attachments</h4>

<p>Message attachments are supported by all forms of Microsoft MAPI. A MAPI attachment can 
be any data file, of any type (text, binary programs, graphics, and so on). These 
attachments are sent to the recipient along with the message header and body. Upon receipt 
of the message, the recipient can, depending on the features of the message client 
software, view, manipulate, and store the attachments on the local workstation. The MAPI 
system keeps track of attachments with a set of properties. Table 4.3 lists an example set 
of attachment properties. The actual properties and their names can differ between program 
code sets.<br>
</p>

<p align="center"><b>Table 4.3. Example MAPI attachment properties.</b> </p>
<div align="center"><center>

<table BORDERCOLOR="#000000" BORDER="1" WIDTH="80%">
  <tr>
    <td><i>Property Name</i></td>
    <td WIDTH="86"><i>Type</i> </td>
    <td WIDTH="377"><i>Description</i></td>
  </tr>
  <tr>
    <td WIDTH="127"><tt><font FACE="Courier">Index</font></tt></td>
    <td WIDTH="86">Long</td>
    <td WIDTH="377">Each message object can contain more than one attachment. Attachments are 
    numbered starting with 0. </td>
  </tr>
  <tr>
    <td WIDTH="127"><tt><font FACE="Courier">Name</font></tt></td>
    <td WIDTH="86">String</td>
    <td WIDTH="377">The name to display in a list box or in the client message area (for 
    example, &quot;June Sales Report&quot;). </td>
  </tr>
  <tr>
    <td WIDTH="127"><tt><font FACE="Courier">Position</font></tt> </td>
    <td WIDTH="86">Long</td>
    <td WIDTH="377">A value that indicates where in the message body the attachment is to be 
    displayed. Microsoft Mail and Windows Messaging clients display an icon representing the 
    attachment within the message body. Other clients may ignore this information, show an 
    icon, or show ASCII text that represents the attachment. </td>
  </tr>
  <tr>
    <td WIDTH="127"><tt><font FACE="Courier">Source</font></tt> </td>
    <td WIDTH="86">String</td>
    <td WIDTH="377">The exact filename used by the operating system to locate and identify the 
    attachment (for example, &quot;\\Server1\Data\Accounting\JuneSales.xls&quot;). </td>
  </tr>
  <tr>
    <td WIDTH="127"><tt><font FACE="Courier">Type</font></tt></td>
    <td WIDTH="86">Long</td>
    <td WIDTH="377">A value that indicates the type of attachment. Microsoft defines three 
    attachment types: <br>
    <i>Data</i>-A direct file attachment<br>
    <i>Embedded OLE</i>-An embedded OLE object<br>
    <i>Static OLE</i>-A static OLE object </td>
  </tr>
</table>
</center></div>

<p>Attachments can be handled differently by the message transport provider. Microsoft 
Mail and Windows Messaging clients display attachments within the message body and 
transport the attachments as part of the message body, too. Microsoft Mail and Microsoft 
Exchange recipients see the attachment within the message body and can use the mouse to 
select, view, and save the attachment when desired. Other transports may handle the 
attachment differently. </p>

<p>SMTP transports will report a message that contains attachments as undeliverable unless 
the transport supports MIME or some other binary transfer protocol. The Internet transport 
that ships with the Windows Messaging Client does support MIME protocol. </p>

<p>The CompuServe service provider for Microsoft Exchange will transport the attachments 
as additional messages addressed to the same recipient. For example, a single ASCII text 
message with one attachment would be received as two messages when sent via the CompuServe 
transport. </p>
<div align="center"><center>

<table BORDERCOLOR="#000000" BORDER="1" WIDTH="80%">
  <tr>
    <td><b>Note</b></td>
  </tr>
  <tr>
    <td><blockquote>
      <p>The CompuServe message transport for Microsoft Exchange supports only attach-ments for 
      native, or CompuServe, addresses. You cannot use the CompuServe transport to send 
      attachments to an SMTP-defined Internet account (such as <tt><font FACE="Courier">[e-mail]</font></tt>). 
      </p>
    </blockquote>
    </td>
  </tr>
</table>
</center></div>

<h3><a NAME="StorageFolders">Storage Folders</a></h3>

<p>MAPI messages can be saved in storage folders. The MAPI model defines several storage 
folders. Figure 4.5 shows a set of folders as viewed from the Windows Messaging Client. </p>

<p><a HREF="f4-5.gif"><b>Figure 4.5 : </b><i>Viewing the folders from the Windows 
Messaging Client.</i></a> </p>

<p>The defined storage folders within MAPI are 

<ul>
  <li><i>Inbox</i>-This is the place where all incoming messages first appear. </li>
  <li><i>Outbox</i>-This is the place where all outgoing messages are placed before they are 
    sent to their destination. </li>
  <li><i>Sent</i>-This is the place where all outgoing messages are placed after they are sent 
    to their destination. This is, in effect, a set of message copies that can be referenced 
    after the original has been sent. </li>
  <li><i>Deleted</i>-This is the place where all messages are placed once they have been 
    marked for deletion. </li>
  <li><i>User-defined folders</i>-This can be one or more folders defined by the user. Each 
    folder can hold messages that have been received and copies of messages that have been 
    sent. </li>
</ul>

<p>Not all implementations of MAPI support all of the folders listed above. For example, 
the Simple MAPI interface allows access to the <tt><font FACE="Courier">Inbox</font></tt> 
(by way of the <tt><font FACE="Courier">.Fetch</font></tt> method of the <tt><font
FACE="Courier">MAPISession</font></tt> Control) and the <tt><font FACE="Courier">Outbox</font></tt> 
(by way of the <tt><font FACE="Courier">.Send</font></tt> method of the <tt><font
FACE="Courier">MAPISession</font></tt> Control). Simple MAPI allows no other folder 
access. Programmers cannot inspect the contents of the <tt><font FACE="Courier">Sent</font></tt> 
folder or move messages from the <tt><font FACE="Courier">Inbox</font></tt> to other 
user-defined storage folders. </p>

<p>The OLE Messaging library offers a more complete access to the MAPI storage system. The 
<tt><font FACE="Courier">Inbox</font></tt> and <tt><font FACE="Courier">Outbox</font></tt> 
folders are accessible by name (that is, <tt><font FACE="Courier">Session.Inbox</font></tt> 
and <tt><font FACE="Courier">Session.OutBox</font></tt>). The <tt><font FACE="Courier">Sent</font></tt> 
and <tt><font FACE="Courier">Deleted</font></tt> folders are available. The OLE MAPI 
implementation allows access to all folders through the <tt><font FACE="Courier">InfoStore</font></tt> 
object. An <tt><font FACE="Courier">Infostore</font></tt> object contains all folder and 
message objects. All MAPI service providers can implement their own message stores, and a 
single client can have access to more than one message store at the same time. Therefore, 
a single MAPI session can involve attaching to several message stores and presenting their 
contents to the user for handling. </p>
<div align="center"><center>

<table BORDERCOLOR="#000000" BORDER="1" WIDTH="80%">
  <tr>
    <td><b>Note</b></td>
  </tr>
  <tr>
    <td><blockquote>
      <p>The OLE Messaging library does not allow programmers to create or delete folders from 
      the <tt><font FACE="Courier">InfoStore</font></tt> collection. Only the MAPI 1.0 API set 
      available from C++ allows programmers to create and delete folders from the storage set. </p>
    </blockquote>
    </td>
  </tr>
</table>
</center></div>

<p>The MAPI storage folders are defined as a hierarchy (as seen in Figure 4.5). The MAPI 
model allows for the creation of multiple levels of the hierarchy at any time. The MAPI 
model allows for the creation of subfolders at any level and on any folder. For example, 
the <tt><font FACE="Courier">Inbox</font></tt> folder can have several subfolders such as 
UnRead, Read, Urgent, and Unknown. The addition of subfolders allows users to organize 
message stores based on use and preference. </p>