Registrations are now open. Join us today!
There is still a lot of work to do on the wiki yet! More information about editing can be found here.
Already have an account?

Microsoft KB Archive/172752

From BetaArchive Wiki

Article ID: 172752

Article Last Modified on 2/12/2007


  • Microsoft Outlook 97 Standard Edition

This article was previously published under Q172752


This article describes the known limitations that you may encounter when you create custom forms and programming solutions with Outlook 97. The issues that are covered in this article include limitations of the object model and other limitations that are related to the architectural design of Outlook.

The following topics are covered in this article:

  • Changing Option Settings
  • Modifying Folder Properties
  • Setting Views
  • Modifying the Outlook Bar
  • Programming Rules for Incoming Mail
  • Posting a File to a Folder
  • Using Office Forms (Office Document Items)
  • Changing the Mouse Pointer to an Hourglass
  • Storing RTF Information in Message Controls
  • Dragging Outlook Items to an OLE Container Control
  • Contact Form Functionality
  • Cut and Paste Functionality


The Outlook object model focuses on folders and Outlook items in folders, not the program itself. This means that while you can manipulate forms and folders, many of the commands or settings that are available through the user interface are not available when you are programming.

When you use the Outlook object model, it is important to note that information is usually set directly to the form item. This may result in different behavior than that when a user types information through the user interface. Many of the Intellisense features are handled at the program level, not the form level. This means that these Intellisense features do not apply when you programmatically modifying forms.

There are also controls and field types that Outlook uses on forms for which the functionality is directly incorporated into the program itself and generally you cannot customize this functionality.

These architectural design considerations are the basis for most of the Outlook programming limitations, and must be taken into account when you design a solution.

NOTE: The scope of this article is limited to Microsoft Visual Basic Scripting Edition (VBScript), and typically does not take into account other possible solutions that use the Active Messaging object model or other Microsoft Exchange-related programming technologies. For more information about these technologies, please consult information provided by the Microsoft Developer Network (MSDN) at the following Microsoft Web site:

NOTE: Because the Microsoft Web site is regularly updated, the site address may change without notice. If this occurs, view the following Microsoft home page:

Changing Option Settings

There is no way to programmatically change any of the program-level settings in Outlook because these settings are not exposed by the object model (for example, any of the settings in the Options dialog box). However, if you initially deploy Outlook in a corporate environment, you may be able to change these setting during Setup using .prf modifications.

For additional information about setting up custom Outlook profiles, click the article number below to view the article in the Microsoft Knowledge Base:

166778 OL97: Contents of the Profile.doc Readme File

Modifying Folder Properties

The Outlook object model does not expose folder properties, such as the default form to use for the folder, synchronization settings, or AutoArchive settings.

Setting Views

There is no way to programmatically set or configure views, which includes all of the options that are listed on the View menu. These options are not exposed by the Outlook object model.

Modifying the Outlook Bar

There is no way to programmatically add folders or items to the Outlook Bar. You must make changes through the user interface.

Programming Rules for Incoming Mail

Because all script written in VBScript is stored within individual Outlook items (such as messages or contacts), there is no simple way to run code (fire an event) when mail enters the Inbox. The Inbox Assistant and Rules Wizard do not provide this functionality.

To work around this limitation, set up a rule by using the Inbox Assistant or Rules Wizard to forward all relevant messages to an "unprocessed" folder, and then create a relatively simple Microsoft Visual Basic program that automates Outlook at regular intervals; the application batch-processes the items in the folder, and then moves or deletes them.

Posting a File to a Folder

There is no way to post a file (as opposed to an Outlook item, such as a contact, appointment, task, and so on) to a folder by using script written in VBScript or the Outlook object model.

Microsoft Word 97 and Microsoft Excel 97 do support a Post method if you want to post a Word document or Excel workbook, but there is no direct way to specify a folder from within those programs. The Post method in these programs displays a dialog box that prompts the user for a folder.

Using Office Forms (Office Document Items)

If you are using a Word Office form, Word does not run any document event procedures, such as the Document_Open event. This is a design limitation of Word and is not specific to Office forms. Word does not support document event procedures when the Word object is embedded within a container application, form, or control.

Changing the Mouse Pointer to an Hourglass

You cannot control the appearance of the mouse pointer by using script written in VBScript. If you write script in VBScript that takes some time to process, you cannot force Outlook to display an hourglass pointer if Outlook does not do it automatically.

Storing RTF Information in Message Controls

Each Outlook item can only have one message (or notes) control to store Rich Text Format (RTF) information, including attachments. You can add more than one control in each form, but the controls are all bound to the same field so they display the same information.

Dragging Outlook Items to an OLE Container Control

You can use an OLE container control on a Visual Basic form to hold objects that you drag to it. When you drag Outlook items to these controls, Outlook exposes only a few fields, and there is no way to change which fields are exposed.

Simulating Contact Form Functionality

You cannot modify any of the default contact form pages. If you create a custom form page, you cannot (or cannot fully) recreate the following default functionality:

  • The Check Names and Address buttons on the General tab of the contact form - When you click these buttons, you receive dialog boxes that cannot be displayed from a custom form page.
  • The e-mail address fields - When you drag a field from the Field Chooser to a custom form page, the e-mail address fields are read-only and you cannot modify them. This is a limitation of the recipient type e-mail address fields, which is not a typical field type for fields and controls.
  • The Birthday and Anniversary fields on the Details page of the form - These fields use a calendar control that is internal to Outlook and cannot be used on a custom form page.

For additional information about replicating the Categories button functionality, click the article number below to view the article in the Microsoft Knowledge Base:

173589 OL97: How to Create a Categories Button on a Custom Form Page

Cut and Paste Functionality

The Outlook object model does not support using the Clipboard in any way.


For additional information about how to create solutions with Outlook 97, click the article numbers below to view the articles in the Microsoft Knowledge Base:

166368 OL97: How to Get Help Programming with Outlook

170783 OL97: Q&A: Questions about Customizing or Programming Outlook

Additional query words: OutSol OutSol97 drag drop drag-and-drop simulate

Keywords: kbhowto kbprogramming kbprb kbofficeprog KB172752