CDO & MAPI Programming with Visual Basic:

Chapter 1. Introduction

Messaging is the transmission of information using electronic means. The information transmitted can be anything: email, documents, images, meeting requests, music, purchase orders, faxes, etc., etc., etc. Anything that can be represented in digital form can be the content of a message. Usually, messaging uses store-and-forward technology. That means that the sender and receiver of a message don’t need to be in direct contact with each other. The sender first gives the message to a messaging server. The server stores the message until it is able to forward it either to the intended recipient or to another server that will forward it to the recipient. That’s the kind of messaging described in this book.

Messaging technology is used for more than just passing messages from one user to another asynchronously. There are natural extensions to this technology that support new ways of communicating and sharing information. For example, you’re familiar with the concept of the discussion list—a use of messaging that enables groups of users to discuss topics of interest in public forums. In addition, message stores can be thought of as databases, providing a central place to store data that is not forwarded but waits for users to come view it. This is the concept behind Microsoft Exchange Server’s public folders. Messaging technology is being used in new and unique ways to manage personal information of all kinds, including schedules, tasks, and contacts. By the time you reach the end of this book, you’ll have learned how to tap into all of this and more in your own programs.

Messaging technology makes people more productive and efficient. Because of the asynchronous nature of email, communicators do not have to coordinate a time when they can both (or all) communicate at the same time. As mentioned, discussion lists are a great example of this. Rather than coordinating a huge meeting where everyone can contribute their opinions, discussion list members can contribute to the list and read others’ communications when and where it’s convenient. Messaging technology makes new things possible.

Messaging technology not only enables humans to communicate more effectively with each other, but also gives humans a new way to communicate with machines, and machines with each other. Web sites can automatically email users when content changes or notify them of events such as stock prices changing or news items appearing. Applications can automatically distribute tasks to personnel and monitor the progress of those tasks. Humans can send email directly to computers to initiate activity on those computers. Computers can email each other using email’s store-and-forward paradigm to queue requests and responses among them.

Microsoft has provided an application-independent architecture for developing messaging and collaboration software. At the core of this architecture is the Messaging Application Programming Interface (MAPI). It is a set of interface specifications to be used by developers of messaging-enabled client and server software. Although the term MAPI refers to this specification, in casual speech (and in writing) it is often used to refer to Microsoft’s MAPI Subsystem, which is the core software component that must be present on a computer in order to run MAPI-based client and server software.

MAPI is a significant departure from traditional messaging systems. It is an attempt to establish open standards to allow different aspects of a messaging system to be written by different software vendors. Prior to MAPI, messaging systems typically were monolithic and proprietary. In contrast, software written to the MAPI standard is immediately compatible with all other MAPI-based software. This allows software vendors to write specific messaging components and ignore the rest. Developers of client applications, for example, needn’t worry about how messages will be stored or transmitted—other components can be purchased by users to fill those needs. Looking at it from the users’ point of view, this allows for mixing and matching of messaging components. (“I like this user interface, but I like that message store.”)

MAPI has a few drawbacks. Because of its depth, it can be hard to learn. MAPI message storage is like a database management system. However, the way information is manipulated in MAPI message stores is not at all what programmers are used to from relational databases. In MAPI, all data—whether it’s email, contacts, audio, invoices, etc.—is stored in entities called message items, which are like records in a database. Within each message item, data is stored in MAPI properties, which are like fields within a record. MAPI is very flexible in that any message item is permitted to possess any set of properties. This is like a database in which the set of fields that define a record can vary on a record-by-record basis. This is a powerful feature, but it takes some getting used to. Another drawback for Visual Basic and VBScript programmers is that MAPI is not directly callable from those languages. To access MAPI features, programmers using these languages can use Simple MAPI, the MAPI ActiveX controls, and Collaboration Data Objects (CDO). All of these technologies are explained in this book, with particular emphasis on CDO.

MAPI has two more strikes against it. First, although it has delivered remarkably well on its promise of breaking email applications into components, this has not kept certain products from becoming dominant. For example, Microsoft Exchange Server is the dominant message store in Windows-based messaging systems. Indeed, some developers regard MAPI simply as the way to access Exchange Server. Finally, MAPI is likely to fade away over the next few years. Internet standards are in the process of replacing MAPI. Even the new version of Exchange Server (Exchange Server 2000) has dumped MAPI in favor of Internet protocols.

In its broadest usage, the term “CDO” refers to a group of messaging technologies, some of them completely unrelated to the others. However, “CDO” is also commonly used to refer to one of these technologies specifically: CDO 1.x, the Visual Basic- and VBScript-friendly “wrapper” for MAPI. That’s how I use the term in this book: “CDO” means “CDO 1.x.” I also touch on some of the other technologies that gather under the big CDO umbrella, but when I do, I qualify the term to differentiate it from the main topic of the book (for example, “CDO for Windows 2000”).

CDO (i.e., CDO 1.x) exposes messaging functionality that is easily accessible to Visual Basic and VBScript programs. Internally, CDO calls MAPI to implement its messaging functionality. CDO is only for developers of client applications; MAPI service providers can’t be written using CDO and therefore can’t be written in Visual Basic. CDO is important because it allows Visual Basic and VBScript developers to get into the messaging game. Messaging frontends, schedulers, discussion lists, document servers, fax-back servers, workflow management systems, and much more can all be written using Visual Basic and CDO. All of these applications can be written for the Web using VBScript and CDO.

The drawback to CDO is that it does not expose all of MAPI’s functionality. As already mentioned, CDO can’t be used for writing MAPI service providers. This is acceptable, since Visual Basic and VBScript programmers are more likely to be interested in writing frontend application software. However, CDO is also missing some nice-to-have features for client applications. For example, CDO provides no way to add Rich Text Format (RTF) text to a message nor to read RTF from a message. This is unfortunate because users have come to expect the ability to use formatted text within messages. (Don’t worry, though, I’ve written a helper component that will do this for you. See Chapter 6, for details.)

Messaging and long-distance collaboration are becoming increasingly important in our connected world. CDO gives your Visual Basic and VBScript applications the ability to participate in this phenomenon. In fact, as developers we may not be able to escape the need to include some messaging awareness in all our applications. In document-based applications, for example, users now expect to be able to email the current document to another user by selecting Send To from the File menu. These basic expectations of collaboration will continue to increase. Using MAPI and CDO to fulfill these needs is what this book is about. Solution developers have an opportunity to make their customers more efficient and productive. I sincerely hope this book helps you to achieve that goal.