Platform SDK: Exchange 2000 Server

Using C++ Header Files

[This is preliminary documentation and subject to change.]

The following sections outline the header files you can use when building applications with Exchange. Each COM component (or group of components) is listed below with a table that contains a list of header files used along with a brief description of each.

Microsoft CDO for Microsoft Exchange (CDOEX)

Include File Description
cdoex.h Contains type information for CDO COM interfaces, COM classes and enumerations.
cdoex_i.c Contains the GUIDs (CLSID, IID, LIBID) for CDO.
cdoexstr.h Contains the string constants used with CDO. These include string constants for Exchange and CDO schema fields.
cdoexerr.h
Contains constant definitions for all of the CDO custom (FACILITY_ITF) error codes.
adoint.h*
Contains the ADO 2.5 Library type definitions. This header is required for CDO to function. It is automatically included within cdoex.h.
adoid.ic*
GUIDs for ADO interfaces and COM classes.

* The adoint.h header is included automatically within the cdoex.h header file. The adoid.ic source file, however, is not.

Microsoft CDO Workflow Objects for Microsoft Exchange (CDOWF)

Reserved for future use. (Use #import. COM server name is cdowf.dll.)

Microsoft CDO Management Objects for Microsoft Exchange (CDOEXM)

Include File Description
cdoexm.h Type information for CDOEXM COM classes, interfaces, and enumerations.
cdoexm_i.c GUID definitions for CDOEXM types.

Note   CDO types and ADO types integrate at the interface level. This means that type information supplied by the ADO interface definitions must be present for CDO to work properly. The cdoex.h header file includes a reference to the ADO header file adoint.h. This header file corresponds to the Microsoft ADO 2.5 Library and should be present in your include path. If you plan to directly create ADO objects, you will also need the file adoid.ic. This file contains the GUIDs for ADO COM classes and interfaces.

Microsoft Active Directory Services Interfaces (ADSI)

Include File Description
activeds.h Type information for ADSI COM classes, interfaces, and enumerations. Additionally contains functions and interfaces useful to C++ programmers. See the ADSI documentation for more information.

OLE DB 2.5 Headers

Include File Description
oledb.h Type information for OLE DB COM classes, interfaces, and enumerations. Additionally contains functions and interfaces useful to C++ programmers. See the OLE DB 2.5 documentation for more information.
oledberr.h Error constants used when programming with OLE DB interfaces. See the OLE DB 2.5 documentation for more information.

Note   When working in C++, you can take advantage of exposed OLE DB interfaces on CDO and ADO objects. If you plan to do so, you should include the OLE DB headers listed above. Use of these interfaces, however, are not required.

Increased build performance.

In many cases, the use of the using namespace XXX directive will significantly reduce the resolution tasks required by the compiler and thereby decrease build times significantly.

#include "cdoex.h" 
#include "cdoex_i.c" 
using namespace CDO;
...code...

If you define CDO_NO_NAMESPACE before you include a CDO header file, the CDO namespace is removed from the type information:

#define CDO_NO_NAMESPACE 
#include "cdoex.h" 
#include "cdoex_i.c"
...code...

Type Conflicts and Namespace Resolution.

When coding in C++ it is possible to include other type declarations, which conflict with CDO types. For example mapidefs.h contains an IMessage type, which produces an error when attempting to program using both cdoex.h and mapidefs.h together. The solution to such conflicts is to use namespaces and then explicitly reference all redundant types. For example:

#include "cdoex.h"
#include "cdoex_i.c"
#include "mapidefs.h"
...
CDO::IMessage* pCDOMessage;
::IMessage* pMAPIMessage;

Examples

Using the CDO Namespace

In the following example, all CDO types are explicitly prefixed with the CDO C++ namespace.

#include "cdoex.h"
#include "cdoex_i.c"
#include "cdoexstr.h"
#include "cdoexerr.h"

#include "emolib.h"
#include "emolib_i.c"

void main() 
{
  CoInitialize(NULL);
  CDO::IMessage*    pMsg    = NULL;
  CDO::IDataSource* pDsrc   = NULL;

  HRESULT hr = CoCreateInstance(CDO::CLSID_Message,
                               NULL,
                               CLSCTX_INPROC_SERVER,
                               CDO::IID_IMessage,
                               reinterpret_cast<void**>(&pMsg));
  hr = pMsg->QueryInterface(CDO::IID_IDataSource, reinterpret_cast<void**>(&pDsrc));

  EMO::IMailRecipient* pMbrecip  = NULL;
  hr = CoCreateInstance(EMO::CLSID_Mailbox,
                               NULL,
                               CLSCTX_INPROC_SERVER,
                               EMO::IID_IMailRecipient,
                               reinterpret_cast<void**>(&pMbrecip));
//...

  CoUninitialize();

}

Importing the CDO Namespace into the Global Namespace

This example imports the CDO namespace into the default, global namespace with the C++ using namespace directive. In this case, you need not use the CDO:: namespace prefix. However, if other types exist with these names, there can be conflicts. For example, MAPI defines a type called IMessage as well. Having MAPI headers in the same module will cause a conflict, and therefore the CDO namespace should be used.

#include "cdoex.h"
#include "cdoex_i.c"
#include "cdoexstr.h"
#include "cdoexerr.h"
using namespace CDO;

#include "cdowf.h"
#include "cdowf_i.c"
//using namespace CDOWF;

#include "emolib.h"
#include "emolib_i.c"
//using namespace CDOEXM;

void main() 
{
  CoInitialize(NULL);
  IMessage*    pMsg    = NULL;
  IDataSource* pDsrc   = NULL;

  HRESULT hr = CoCreateInstance(CLSID_Message,
                               NULL,
                               CLSCTX_INPROC_SERVER,
                               IID_IMessage,
                               reinterpret_cast<void**>(&pMsg));
  hr = pMsg->QueryInterface(IID_IDataSource, reinterpret_cast<void**>(&pDsrc));

...

  CoUninitialize();

}