Information
stores provide a structure and container for your data; forms are
predefined "boxes" used to input and view that data. When
you open a record, Outlook retrieves the required information from
the store and displays it in a form. Forms are also customizable in a
variety of ways, and, in combination with VBA and VBS (see Chapter 18), allow you to create custom applications that
leverage Outlook's existing data structures. Later in the
section we'll show you how to build a template using a form.
Figure 3-7 shows a typical form. Recognize it?
That's correct, the default Outlook email editor is actually a
form. Forms are also what you see when you open a record in Calendar,
Contacts, Tasks, Notes, and Journal.
In addition to letting you enter/view data, the fields on a form may
contain formatting rules. The name, address, and phone fields on the
General page of a Contact form, for example, have parsing
capabilities to help you fill in names and addresses correctly. These
capabilities are built in to the Outlook executable, so you
won't see the rules in the control's properties sheet.
When you save an entry, the form simply hands off all its fields to
Outlook, which then stores this data dutifully away—in the
format provided—in your database.
Much of
Outlook's
functionality for collaboration centers on exchanging data as email
or attachments to email. When Outlook exchanges a message with
another email client, that data is bundled in a combination of text
and a proprietary
binary
attachment (typically, winmail.dat); inside this
binary attachment are the specifications for the form Outlook wants
to use to display the data. The email client on the receiving end
opens the message, reads the text, and tries to decipher the form
Outlook wants the data displayed in.
This explains why some messages are not always translated as
intended. When another email client (sometimes another Outlook email
client using a different message format) receives a message and it
does not understand the attached