The
Microsoft® Outlook™ desktop information manager Object Library is an ideal integration
tool because it enables complete access by other Microsoft Office applications
to the data stored within Outlook. With the Outlook Object Library, you can
make Outlook tasks, appointments, journal items, and notes accessible to other
applications. All the data and functionality associated with each item are
available through the Outlook Object Library.
The Outlook Object Library is
functionally, although not syntactically, compatible with the OLE automation
layer available in Microsoft Schedule+ 7.0. So, just as you create a recurrent
appointment using the Schedule+ OLE automation layer, you also can create one
in the Outlook Library, although not with the same code.
The left
branch, under Namespace, contains the Data Access Objects available within
Outlook. The Microsoft Explorer and Inspector branches represent the user
interface frames. The Assistant is the Microsoft Office Assistant, known as the
Paperclip, or the Microsoft Office Logo.
Because
it is an integrated part the Microsoft Office product family, the Outlook
Object Library provides you programmatic access to the Office command bars.
Using the bars at the top of the frames, you can add and delete commands, menu
items, and the Assistant, all programmatically.
Another
important aspect of the Outlook Object Library is its support for separation of
the user interface and data. The root Application object, for example, enables
you to create a new mail message with one line of code. This is a key
difference between the Outlook Object Library and the Collaboration Data
Objects library and MAPI. The Outlook Object Library is tailored for an Office
developer, and so it provides the highest possible ratio of functionality to
lines of code.
Folders
and items are the main data objects in the Outlook Object Library, and
virtually everything you can do with the library boils down to manipulating
folders and items. The Inspector and Explorer objects are user interface
objects for item and folder, respectively.
The
application object enables one-step creation of new Outlook Items through a
method called “CreateItem.” Note that the library supports a number of
predefined enumerated constants such as olMailItem or olAppointmentItem, which
enable you to pass item values through a Microsoft Visual Basic® development
system setting. You then can obtain the currently active user interface objects
such as ActiveExplorer or ActiveInspector and, in turn, the current item or
folder. The Application object is also the main entry point into the rest of
the data store.
To get
the Namespace object from the Application object in its original design, use
the GetNamespace method. In building the current release, Outlook Object
Library designers found that the only available Namespace was the MAPI
Namespace—which means that all the information goes into the MAPI store. Using
the MAPI namespace, you can access all appointments, journals, and other Outlook
items stored either in PST or OST or on a Microsoft Exchange server.
The
MAPI Namespace is roughly equivalent to the MAPI.Session in CDO or Active
Messaging. It provides the same current user, logon, and logoff capabilities.
It enables you to specify a logon profile, for example. It also tracks and
provides you the root folders collection, which you can use to navigate into
the data that’s stored within a PST, OST, or Exchange Server folder. So, the
folders property for the Namespace object contains the root folder for each of
the stores that’s within your profile. If you have a personal folder, as well
as your Exchange Store, you have two entries in the folders collection, which
are the roots into them.
Simplifying Coding
In
keeping with the goal of the Outlook Object Library to simplify coding,
GetDefaultFolder provides a shortcut to a client’s default folder, be that the
contacts, tasks, or calendar folder. In addition, tasks are stored in a task
folder, appointments are stored in the calendar, and so on. All folders that
are special to Outlook are created automatically when you create the account.
Once you get the Namespace object, you can go directly to that special
folder—the default folder used for the entire profile—wherever it resides
within the store.
Also in
the item collection are a number of new properties and methods enabling you to
specify search criteria. You can use these properties and methods to prefilter
data and then, as you sift through the collection, only the items that match
will be there. This capability gives you a powerful way of getting to data
quickly.
Since
calendaring is such an important deployment concern, the Outlook Object Library
also provides a programmatic way of sharing calendars. Note that the term is
“share” rather than “delegate” because the functionality implies more than just
a delegated relationship. Whenever one user designates a folder to be shared
with another user, the second user has privileges to access the folder
programmatically.
Other
item types within Outlook expose the functionality of the user interface. The
contact item, for example, has a defined set of 130 to 140 properties
representing the data that can be stored on a contact, such as multiple addresses,
phone numbers, and so on.
The Outlook Object Library designers took the
different types of data that developers can store in Outlook and created
objects representing each of them and properties and methods enabling you to
execute advanced functionality through the user interface. Also included are
properties such as subject and creation time that are guaranteed to be
implemented on every item type.
To book an appointment in someone else’s calendar, you get the
Namespace, create a recipient (the person whose calendar you’re accessing), get
a user object back from that, and ensure that it is resolved against the global
address list. This gives you a valid user object. With
Namespace.GetSharedDefaultFolder, you pass in the user object and default folder
type that you want, and Outlook returns the calendar.
A
number of characteristics are specific to the given item types and properties.
For example, in task and appointment items, there are starting times and end
times. There are also methods, such as a start timer and a stop timer, in the
journal. This arrangement enables you to get an item, start the timer in the
background, and perhaps display it for the user or display a simpler user
interface for the user for taking notes. When the user is finished with the
operation, he or she can execute the stop timer. You simply put all that
information into the item and save it.
A
number of objects are specific to certain item types. The appointment and task
objects, for example, have a recurrence object. This object is easily
programmable. For example, using specific functionality connected to an
appointment item, you can set up a weekly meeting that occurs every Monday at 2
p.m. In addition, common collections Attachments and User Properties, which are
connected to every item, enable you to do more common tasks, such as adding an
office document or any other file as an attachment, or customizing Outlook
forms using custom user-defined fields.
Microsoft Visual Basic Scripting Edition
(VBScript) is a subset of the full Visual Basic language used in Microsoft
Internet Explorer and a number of other Microsoft products. It’s an ideal
engine for designing a form, developing it, and sending it, because for those activities
you don’t need the power and complexity of having full Visual Basic code behind
your Item. VBScript enables programmability within the form while keeping the
paradigm simple so that you’re not overly burdened and the resulting code and
item size remain within constraints. (For more information, see the Web site
for VBScript under Microsoft.com, which documents the Visual Basic features
that are supported by VBScript.)
Note,
however, that if you’re planning to move Outlook forms to the Web, to use CDO
and Active Server Pages on the server, or to display Outlook forms in a
browser, you should try to limit your use of the Forms3 Object model. That is,
you should limit your use of VBScript accessing the user interface because
objects from the Forms3 Object library aren’t available in the CDO object
model.
Items provide the only place you can program
within Outlook itself. For designing forms, VBScript makes a number of events
available, including open and close as well as read and write from the store.
When a property change occurs, that is, when you set a value within one of your
form controls and you tab off it, Outlook changes the underlying property,
yielding an event within your script that is notified of that; you can then
program it.
For
example, if you customize a message and send it to a user, and the user opens
it and selects Reply, you receive an event enabling you to perform
sophisticated data copying from the original to the follow-on form, such as
removing some text from the message body. This means you can link standard
actions such as Reply, Reply All, and Forward to your own custom actions.
The Item keyword is prebound for you within
your VBScript code, so that when it executes and the Script engine loads, you prepopulate
the environment with
the item that is in context. For example, when a user opens an Outlook item,
the object model and any Visual Basic Scripting Edition that calls the object
model know which item is open and can access fields in that item such as
subject, time received, and so on.
Microsoft has added a security layer to the
Outlook Object Library items so that if you publish a form definition into an
Exchange Form Library—be it the folder’s forms library, the organizational
forms library, or a personal forms library—that form is considered safe,
because those libraries are locked. When you send the form using a definition
from one of those libraries, the form opens automatically on the recipient’s
desktop, without any warning, because there’s no way it can contain any errant
code.
Then
there is the idea of a one-off form. This is an unpublished form that you
design, create an instance of, and send to someone. The one-off form carries
the form definition and code with it so that when the recipient pulls it from
an inbox, the standard Office warning asks whether the user wants to enable or
disable macros as the item opens.
Note
also that the form can be accessed through the item keyword in its VBScript and
has parents, that is, the folder in which the script lives. This means it also
has an application property enabling you to return to the application. Because
of this characteristic, you can go anywhere in the Object Library from the item
and perform powerful functions. For example, through the script, you could open
a journal Item and check to see whether this item exists in that folder.
In
VBScript, cancelable events do not use a return value per se but instead a
function syntax, wherein you set the function name to your return value. For
example, in a form where data should be only read but not saved, the following
code would cause Outlook to not save any changed data:
Function Item_Write()
Item_Write = False
End Function
Outlook
provides a number of constants enabling you to avoid having to deal with digit
values. Unfortunately, those constants aren’t available or supported in the
Script engine. Instead, the Help file enumerates these constants and documents
their decimal values. For more information on these constants, please refer to
the Outlook Object Library Help File, which is included under the Valupack
subdirectory on the Office 97 or Outlook CD-ROM.
The
Exchange Client Extensions are COM-based interfaces, developed in Microsoft
Visual C++® development system that constitute key parts of many Exchange
solutions. Microsoft used the extensions to develop the original Exchange Rules
Wizard as well as some functionality supporting security, workflow, and access
to external applications.
As part
of Microsoft’s goal of the original Outlook release, the product runs any
well-behaved extension, and so the Exchange Client extensions have become a
powerful way of extending Outlook. Some 20 or 30 such extensions are operating
currently within Outlook. Their execution in Outlook differs from their
execution in Exchange in that Outlook doesn’t enable an extension to access the
product’s user interface, that is, to directly manipulate HWNDs. Instead,
Outlook reads the registry information only once for an extension and, for
performance reasons, transfers it to an internal cache.
Other
differences involve the Install commands. In striving to make Outlook fully
compatible with the Exchange client, Microsoft emulated the Exchange menu
structure so that extensions expecting that menu structure could determine
where to put their command. These extensions would then be “fooled” when
running under Outlook.
Outlook
also supports an additional interface on the extension callback that you get by
default with the Exchange Client extensions. This interface enables you to
retrieve an object from the Object Library. This capability is extremely
powerful for two reasons. One, client extensions now can reach directly into
the Object Library and use all the power that the Callback exposes there. Two,
an extension can determine whether the callback exists and whether you’re
running under Outlook or Exchange.
Please
note that the current Outlook implementation of one callback method, namely
GetVersion, returns zero when it should return a build number. This means any
extension based on that method will malfunction. Note also that Microsoft is
addressing the problem and plans to have it resolved by the first half of 1998.
When you install an extension in Outlook, you
essentially install the DLL as you would on any Microsoft Windows® operating
system based system. Take note that Microsoft discourages installing the extensions
into the Windows subdirectory and recommends instead that you place the
extension in a predefined addins directory under the Outlook Install Share.
Also note that to have Outlook automatically rebuild its cache on next startup,
you must add the following data under the hklm\machine\Software\Microsoft\Exchange\Client\Extensions
portion of the registry: “Outlook Setup Extension
4.0;Outxxx.dll;7;00000000000000;0000000;OutXXX.”
If
you’re running in an Outlook-only environment or do not care about this
Extension running under the Exchange Client, you need only an ECF, which is a
configuration file used by Outlook to boost the performance of extensions.
Through an ECF, the extension informs Outlook about important contexts, menus,
events, interfaces, and other items of interest to it. Outlook stores the
information and calls the relevant extensions only for events it needs.
Once
you’ve installed your ECF and the DLL to add to registry, Outlook accesses the
registry key and, based on the information in it, rebuilds the cache with the
newest information. Note that you need not worry about losing user settings
during this process.
With
the vast capabilities of the Outlook Object Library, you can programmatically
access multiple functions of Outlook, incorporate VBScripts into built-in
Outlook forms for customizing and integrating them with other applications, and
manipulate other data from within the forms. The Outlook Object Library also
supports Exchange Client Extensions for an added method of implementing
security and workflow functionality and providing access to external
applications.
For the latest information on Microsoft
Exchange 5.5, check out our World Wide Web site at
http://www.microsoft.com/exchange.
Microsoft Exchange 5.5