This article was previously published under Q244764
This article has been archived. It is offered "as is" and will no longer be updated.
Microsoft Outlook 2000 requires that all Messaging Application Programming Interface (MAPI) forms support Automation by implementing IDispatch. Forms which worked in previous builds of MAPI may not work reliably in Outlook 2000 unless they implement IDispatch. Adding IDispatch support to a MAPI form may not interfere with its performance on previous builds of Outlook.
The following Visual Basic code can cause unexpected errors when run against a MAPI form which does not implement IDispatch. A common error is that four instances of the form server are launched.
Private Sub Command1_Click() Dim MyApp As Outlook.Application Dim MyNamespace As Outlook.NameSpace Dim MyFolder As Outlook.MAPIFolder Dim MyItem Set MyApp = CreateObject("outlook.application") Set MyNamespace = MyApp.GetNamespace("MAPI") Set MyFolder = MyNamespace.GetDefaultFolder(olFolderInbox) Set MyItem = MyFolder.Items.Add("IPM.CLASSOFYOURFORM") MyItem.DisplayEnd Sub
Outlook expects to call Display through an automation interface. When QueryInterface for IID_IDispatch stops responding, Outlook interprets this as an error and tries again. Depending on how the form is coded, this can cause multiple instances of the form to appear.
To simply implement a skeleton of IDispatch and provide access to it through the form's QueryInterface implementation is enough to enable Outlook to behave with the form. Standard Outlook Form commands, such as Display and Close, still do not work unless you expose them through IDispatch::GetIDsOfNames and IDispatch::Invoke.
In order to speed the execution of certain common verbs, Outlook expects that some commands always use the same DISPID, such as 0xF0A6 for Display and 0xF023 for Close. These DISPID's can be discovered by watching which DISPID's are passed to Invoke.
To see a sample form which implements IDispatch, check out
246524 SAMPLE: MAPI Form Which Implements IDispatch