Microsoft Outlook 2002 Developer FAQ

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

Acey Bunch and Bill Jacob
Microsoft Corporation

November 2001

Applies to:
     Microsoft® Outlook® 2002

Summary: This article highlights common questions and concerns of developers who are learning to develop solutions using Microsoft Outlook 2002. (9 printed pages)

Contents

I am new to developing Outlook solutions; is there a good place to start learning how to do this?
What are the various approaches for creating Outlook solutions?
What are the different approaches to Outlook security?
What is a custom form and how do I use one?
What are custom fields?
What is a one-off form?
How do I import data from an Access database and insert it into an Outlook custom field?
How do I export data from an Outlook custom field and insert it into an Access database?
How do I print a form?
What is the Outlook object model and how do I use it?
How do I deploy a custom solution?

Introduction

Like other Microsoft® Office applications, Microsoft Outlook includes an object model and the Visual Basic® for Application (VBA) editor that can be used to manipulate the object model. Outlook also includes the ability to develop custom forms and fields that, when combined with the object model, can be used to develop custom solutions. Microsoft product support professional Bill Jacob deals daily with customers who build Outlook solutions. Based on the direct customer feedback he receives, Bill has compiled the following responses to common questions that Outlook solution developers often ask.

Note   All information in this article also applies to Microsoft Outlook 2000, but links contained in this article reference Microsoft Outlook 2002 resources.

Frequently Asked Questions

I am new to developing Outlook solutions; is there a good place to start learning how to do this?

Absolutely! The best place to start is the Office Developer Center, which is where this FAQ is posted. See the article Developing Solutions with Outlook 2002, which provides a general overview of Outlook development. Also, see the Microsoft Knowledge Base article OL2002: Resources for Custom Forms and Programming for a list of Web sites, articles, books, and magazines that focus on Outlook solution development.

What are the various approaches for creating Outlook solutions?

There are at least four main approaches to developing Outlook solutions. One is to use Visual Basic® for Applications (VBA) or a Component Object Model (COM) add-in to automate the Outlook application itself. The second approach is to use Visual Basic Scripting Edition (VBScript) to develop interactive Outlook forms. The third approach involves using a COM-compliant language such as Microsoft Visual Basic or Microsoft Visual C++® to automate Outlook using the Microsoft Outlook 10.0 Object Library. The fourth approach is to associate a custom HTML page with an Outlook folder, much like a digital dashboard. In addition, you can interact with other components such as a Microsoft SQL Server database, Microsoft Exchange Server, or other programs.

In general, an Outlook solution involves manipulating the user interface (either Outlook's built-in forms or new custom forms), creation of some programming code (either VBA, VBScript, or a COM-based language), and any extra interaction with outside components such as a database or mail server.

What are the different approaches to Outlook security?

You must consider many different aspects of security when developing an Outlook solution. Such aspects include Outlook attachment behavior, the Outlook object model, Collaboration Data Objects (CDO), Simple Messaging Application Programming Interface (Simple MAPI), and other general issues such as security zone settings.

As an Outlook solutions developer, you should consider your security needs based on your target customers. If your customers are internal then you may wish to reduce some of the security levels.

The first type of security is related to VBScript in Outlook custom forms. This type of security has existed since the first version of Outlook. When using a custom form, the VBScript (along with the entire form definition) can be stored either in a published location or within individual items. In order for the code to be trusted it must be in a published location. If the code is located directly within an item, when a user opens the item, Outlook will display a security warning and prompt the user either to enable or disable macros. For more information about VBScript-based code security, please see the Knowledge Base article OL2002: Why Outlook Displays a Security Warning Message When You Open an Item.

The second type of security parallels the VBA and COM add-in security models in other Office programs. To access this feature, click the Tools menu, point to Macros, and then click Security. One important difference in Outlook, however, is that VBA is not designed to be deployed, since VBA code is not stored in users' files such as Microsoft Word documents, Microsoft Excel spreadsheets, and Microsoft PowerPoint® presentations. Also, the Outlook object model does not allow you to automate the Visual Basic Editor to deploy code, so the risk of VBA-related security issues is generally less of a concern in Outlook than in other Office programs.

The third type of security, however, affects all types of solutions, since it is directly integrated into the Outlook object model. Designed to prevent the spread viruses through e-mail, this security feature was originally released as an update to Outlook 2000 Service Release (SR) 1, and was then included in Outlook 2000 Service Pack (SP) 2 and Outlook 2002. For more information about these newest security features, please see the Microsoft Knowledge Base article OL2002: Developer Information About E-Mail Security Features.

What is a custom form and how do I use one?

Outlook custom forms are based on VBA UserForms, but they operate quite differently from a form design perspective. Like many development environments, there is a clear distinction between data and the user interface. An Outlook item in a folder represents data much like a record in a database table. On the other hand, a form is the user interface that displays the data in a specific format.

Items and forms are linked by a field on an item called a message class. When Outlook opens an item, it checks the message class field and uses the form specified in that field. For example, a standard contact form uses the message class of IPM.Contact. When you create a custom form based on the standard Outlook contact form, you give it a name; this name serves to differentiate the custom form from the standard form. If the name of the custom form is "Business," then the message class used to represent that form is IPM.Contact.Business. For more information about message classes, please see the Microsoft Knowledge Base article OL2002: How to Update Existing Items to Use a New Custom Form.

Outlook custom forms are published rather than saved. In Outlook, the term save relates to saving an item in a folder. However, forms are published in a location so that they can be used later or shared. If you create a folder-based solution, you typically publish the form into the folder that contains the solution. If you create a custom mail message form, you typically publish the form in the Microsoft Exchange Server Organizational Forms Library so that everyone has access to it. For more information about publishing forms, please see the Microsoft Knowledge Base article OL2002: How to Determine Where to Publish a Form.

It is important to follow some best practices when designing Outlook forms. Most of these practices relate to the difference between data (items) and the user interface (forms).

• Form design process
  To design an Outlook custom form, you must start with one of the default forms. You should not open an item in a folder and enter design mode. Instead, open a new item and then enter design mode. After making changes, publish the form. When you close the form, you are prompted to save changes. Although it may seem counterintuitive, you should always click No to this prompt because the form was just published and therefore stored. If you click Yes, Outlook will create an item in a folder, and this is not the desired result. To make further changes to a form, always open a new instance of the published form, make changes, and then republish. You should never open an item in a folder and enter a design mode; otherwise, existing data will be saved in the published form and other side effects may occur.
• **Understanding fields and controls
  **When designing custom forms, it is important to realize that items contain fields to store data. Likewise, forms contain controls to display the data. Much like the message class field links an item to a form, you typically must link, or bind, a field to a control. If you just use the Control Toolbox to add controls to a form, the form will not preserve any data when an item is saved or sent because controls do not store data. For more information about using fields and controls, please see the Microsoft Knowledge Base article OL2002: Overview of Using Fields and Controls on Custom Forms.
• **Outlook object model
  **After using the Outlook object model for a while, you will notice that many parts of the object model distinguish between data and the user interface. The terms explorer and inspector, for example, refer to an item's windows, while the term item refers to an object that represents the collection of fields. Also, the way you reference fields in the Outlook object model is quite different than the way you reference controls on a form.

What are custom fields?

Also known as a user-defined field, a custom field is a type of container in which you can store information of varying types. Custom fields can be created for folders, items, or forms. Custom fields work similarly to fields in a database table. However, the information they store is not relational, but rather stored in a somewhat flattened format. When creating a custom form, controls on the form can be bound to custom fields.

Custom fields can have the following data types:

For more information about custom fields in Outlook solutions, please see the Microsoft Knowledge Base article OL2002: Working With User-Defined Fields in Solutions.

What is a one-off form?

A one-off form is a customized form that contains its own form definition information. You may want to use this type of form when you cannot publish your custom form to the Organizational Forms Library on a Microsoft Exchange Server. The form definition includes information about the components of the custom form. You can specify that a form is a one-off by setting the Send form definition with item checkbox in the form's Properties page in design mode.

For more information about one-off forms in Outlook solutions, please see the Microsoft Knowledge Base article OL2002: Working with Forms Definitions and One-Off Forms.

How do I import data from an Access database and insert it into an Outlook custom field?

Although Outlook has a built-in data import and export feature, it does not support the importing and exporting of custom fields. To import data from a Microsoft Access database and insert it into an Outlook custom field, you will need to write programming code. You will need to use a data access component such as ActiveX® Data Objects (ADO) to extract the information from Access. Then, using the Outlook 10.0 Object Library, insert the information into an Outlook object such as a contact or some other item. You can use several different approaches to accomplish this, such as writing code in an Access module to push the data into Outlook, or writing code in an Outlook module to pull the data from Access.

For more information about importing Access data in Outlook solutions, please see the Microsoft Knowledge Base article OL2002: How To Programmatically Import Outlook Items from Microsoft Access.

How do I export data from an Outlook custom field and insert it into an Access database?

To export custom field data from Outlook and store it in an Access database, you also need to write some programming code. Here again you will use the Outlook 10.0 Object Library to extract data from an Outlook object. Then, using a data access component like ActiveX Data Objects (ADO), make a connection to an Access database and insert the data into a table.

For more information about exporting Outlook data to an Access database in Outlook solutions, please see the Microsoft Knowledge Base article OL2002: How To Programmatically Export Outlook Items to Microsoft Access.

How do I print a form?

Outlook can only print forms using options that are available in the Print dialog box. While you can customize the print style settings using the options provided in the Define Print Styles dialog box, you cannot change the basic format that Outlook uses for displaying forms. In addition, the Outlook object model does not provide any methods or properties for changing a form's print format.

There are a number of approaches to customizing the print format of forms, depending on the form type and the print mode. One approach is to simply use ALT+PRINT SCREEN to copy the image to the Clipboard, and then paste the contents of the Clipboard into another program to print the form. Another approach is to create a custom report programmatically by using the Outlook 10.0 Object Library to extract the desired information, and then use another object model like the Word 10.0 Object Library to create a document with the desired Outlook data.

For more information about printing forms in Outlook solutions, please see the Microsoft Knowledge Base article OL2002: Outlook Does Not Print Forms as Expected.

What is the Outlook object model and how do I use it?

The Outlook Object Model is a set of programmatic interfaces that allow to you automate certain features of Outlook using programming code. To use the Outlook object model, you must first set a reference to the Outlook 10.0 Object Library. If you are using the VBA editor that is built-in with Outlook, this reference is already set for you. Once you have set a reference to the Outlook object model, you can then write programming code to create an instance of Outlook and begin working with common Outlook components such as folders, e-mail messages, and contacts. The following example demonstrates the use of VBA code to open an instance of Outlook and display the number of messages currently in the Inbox:

Private Sub CountInboxMessages()
'This procedure displays a message box that indicates the number of 
'messages currently in the Inbox.

    Dim objOutlook As Outlook.Application
    Dim objNamespace As Outlook.NameSpace
    Dim objMAPIFolder As Outlook.MAPIFolder

    Set objOutlook = New Outlook.Application
    Set objNamespace = objOutlook.GetNamespace(Type:="MAPI")
    Set objMAPIFolder = objNamespace.GetDefaultFolder(olFolderInbox)

    MsgBox "You have " & objMAPIFolder.Items.Count & _
      " messages in your Inbox.", vbInformation

    Set objMAPIFolder = Nothing
    Set objNamespace = Nothing
    Set objOutlook = Nothing

End Sub

For more information about using the Outlook object model in Outlook solutions, please see the Microsoft Knowledge Base article OL2002: Programming Examples for Referencing Items and Folders.

How do I deploy a custom solution?

You can use a variety of means to create a custom Outlook solution. How you deploy the solution depends largely on how the solution is designed and who the intended audience is that will be using it. Some of the more common scenarios include the following:

• **Custom mail message forms
  **Custom mail message forms need to be available to everyone in the organization and therefore should typically be published in the Organizational Forms Library on a Microsoft Exchange Server. As long as you don't integrate custom components that are not available on the users' computers, you do not need to worry about installing any additional components.
• **Custom folder solutions within the organization
  **These types of solutions are typically created in public folders on an Exchange Server. The ideal solution would be to create the folder in the location that it will eventually be used, and then limit permissions to the folder to only developers. When the solution is complete, you then give the users permissions on the folder and send a notification that it is available. An alternative is to create the folder in your own mailbox or in a Personal Folders file, and then copy the folder to the public folder hierarchy after completing the solutions. However, some types of items may behave differently in a public folder, so it is safer to develop the folder in the environment in which it will be used. In particular, tasks behave differently depending on whether they are stored in a public folder or a personal folder. In a public folder, tasks cannot be assigned to another person.
• Custom folder solutions outside the organization
  If you are developing a folder-based solution that needs to be deployed to another company, you can transfer the folder by storing it in a Personal Folders file (.pst). To do this, first add a Personal Folder file to your set of Outlook folders. On the File menu, point to New, and then click Outlook Data File. Then copy the public folder into the new set of folders in your folder list. To close the Personal Folders file, right-click the top-most folder and then click Close. Be sure to exit Outlook before trying to move the .pst file. Once the .pst file is copied to the other company's machine, open it using the same procedure as above. Then copy the folder to the public folder store, and close the .pst file so Outlook does not continue to try to open it.
• Folder deployments
  If you need to deploy one or more folders to another organization or to standalone computers, you can create a solution to do this using the Outlook object model. Beginning with Outlook 2000, you can use the AddStore and RemoveStore methods to add and remove Personal Folders files from the MAPI profile. Therefore, if your folder solution is stored in a Personal Folders file, you can programmatically:
• Add the Personal Folders file to the profile using the AddStore method.
• Use the MAPIFolder.CopyTo method to copy the folder to its destination location.
• Remove the Personal Folders file from the profile using the RemoveStore method.
• **Outlook Visual Basic for Applications
  **Unlike other Microsoft Office programs that support Visual Basic for Applications, Outlook Visual Basic for Applications code was not designed to be deployed; rather, it is considered to be a personal development environment. If you need to deploy an application-level solution, you should use the COM add-in architecture instead, and then you can create a setup program to deploy the COM add-in. For more information about VBA project files in Outlook, please see the Microsoft Knowledge Base article OL2002: Code Does Not Work After You Distribute a VBA Project. For more information about COM add-ins with Outlook, please see the Microsoft Knowledge Base article OL2002: How to Create a COM Add-in for Outlook.

Some other issues to keep in mind when deploying Outlook solutions are:

• An Outlook folder should be considered similar to a Visual Basic project—it stores an entire solution. For a folder-based solution, always copy the entire folder. This will ensure that all of the forms, views, fields, and folder properties are copied. If you publish only the custom form to another folder, problems and side effects may occur.
• Exchange and Outlook do not provide functionality to distribute ActiveX components, so if you use custom controls or components on an Outlook form, you must deploy these components.
• Many Outlook solutions use the Collaboration Data Objects (CDO) object model to provide MAPI-related functionality. However, CDO is not installed by default by Office setup, so you must ensure that it is installed on the end users' computers before you try to use it. Note that while many features in Office can be installed on demand, CDO cannot be installed on demand.

Additional Resources

For more information about the technologies that you can use when developing Outlook solutions, please visit the following Web resources:

• Outlook Product Page
• Office Developer Center
• Exchange Server Developer Center
• Windows Script Developer Center
• Visual Basic for Applications Home Page