Name 

Description 

Creating Simple COM Servers: Overview 

Delphi provides wizards to help you create various COM objects. The simplest COM objects are servers that expose properties and methods (and possibly events) through a default interface that clients can call.
Two wizards, in particular, ease the process of creating simple COM objects:

• The COM Object wizard builds a lightweight COM object whose default interface descends from IUnknown or that implements an interface already registered on your system. This wizard provides the most flexibility in the types of COM objects you can create.
• The Automation Object wizard creates a simple Automation object whose default interface descends from IDispatch.... more 

Designing a COM Object 

When designing the COM object, you need to decide what COM interfaces you want to implement. You can write a COM object to implement an interface that has already been defined, or you can define a new interface for your object to implement. In addition, you can have your object support more than one interface. For information about standard COM interfaces that you might want to support, see the MSDN documentation.

• To create a COM object that implements an existing interface, use the COM Object wizard.
• To create a COM object that implements a new interface that you define,... more 

Using the COM Object Wizard 

The COM object wizard performs the following tasks:

• Creates a new unit.
• Defines a new class that descends from TCOMObject and sets up the class factory constructor. For more information on the base class, see Code generated by wizards.
• Optionally, adds a type library to your project and adds your object and its interface to the type library.

Before you create a COM object, create or open the project for the application containing functionality that you want to implement. The project can be either an application or ActiveX library, depending on your needs. 

Using the Automation Object Wizard 

The Automation object wizard performs the following tasks:

• Creates a new unit.
• Defines a new class that descends from TAutoObject and sets up the class factory constructor. For more information on the base class, see Code generated by wizards.
• Adds a type library to your project and adds your object and its interface to the type library.

Before you create an Automation object, create or open the project for an application containing functionality that you want to expose. The project can be either an application or ActiveX library, depending on your needs. 

COM Object Instancing Types 

Many of the COM wizards require you to specify an instancing mode for the object. Instancing determines how many instances of your object clients can create in a single executable. If you specify a Single Instance model, for example, then once a client has instantiated your object, COM removes the application from view so that other clients must launch their own instances of the application. Because this affects the visibility of your application as a whole, the instancing mode must be consistent across all objects in your application that can be instantiated by clients. That is, you should not create... more 

Choosing a Threading Model 

When creating an object using a wizard, you select a threading model that your object agrees to support. By adding thread support to your COM object, you can improve its performance, because multiple clients can access your application at the same time.
The following table lists the different threading models you can specify.
Threading models for COM objects  

Defining a COM Object's Interface 

When you use a wizard to create a COM object, the wizard automatically generates a type library (unless you specify otherwise in the COM object wizard). The type library provides a way for host applications to find out what the object can do. It also lets you define your object's interface using the Type Library editor. The interfaces you define in the Type Library editor define what properties, methods, and events your object exposes to clients.

Managing Events in Your Automation Object 

The Automation wizard automatically generates event code if you check the option, Generate Support Code in the Automation Object wizard dialog box.
For a server to support traditional COM events, it must provide the definition of an outgoing interface which is implemented by a client. This outgoing interface includes all the event handlers the client must implement to respond to server events.
When a client has implemented the outgoing event interface, it registers its interest in receiving event notification by querying the server's IConnectionPointContainer interface. The IConnectionPointContainer interface returns the server's IConnectionPoint interface, which the client then uses to pass... more 

Automation Interfaces 

The Automation Object wizard implements a dual interface by default, which means that the Automation object supports both

• Late binding at runtime, which is through the IDispatch interface. This is implemented as a dispatch interface, or dispinterface.
• Early binding at compile-time, which is accomplished through directly calling one of the member functions in the object's virtual function table (VTable). This is referred to as a custom interface.

wizard that do not descend from IDispatch only support VTable calls.  

Dual Interfaces 

A dual interface is a custom interface and a dispinterface at the same time. It is implemented as a COM VTable interface that derives from IDispatch. For those controllers that can access the object only at runtime, the dispinterface is available. For objects that can take advantage of compile-time binding, the more efficient VTable interface is used.
Dual interfaces offer the following combined advantages of VTable interfaces and dispinterfaces:

• For VTable interfaces, the compiler performs type checking and provides more informative error messages.
• For Automation controllers that cannot obtain type information, the dispinterface provides runtime access to the object.
• For... more 

Dispatch Interfaces 

Automation controllers are clients that use the COM IDispatch interface to access the COM server objects. The controller must first create the object, then query the object's IUnknown interface for a pointer to its IDispatch interface. IDispatch keeps track of methods and properties internally by a dispatch identifier (dispID), which is a unique identification number for an interface member. Through IDispatch, a controller retrieves the object's type information for the dispatch interface and then maps interface member names to specific dispIDs. These dispIDs are available at runtime, and controllers get them by calling the IDispatch method,GetIDsOfNames.
Once... more 

Custom Interfaces 

Custom interfaces are user-defined interfaces that allow clients to invoke interface methods based on their order in the VTable and knowledge of the argument types. The VTable lists the addresses of all the properties and methods that are members of the object, including the member functions of the interfaces that it supports. If the object does not support IDispatch, the entries for the members of the object's custom interfaces immediately follow the members of IUnknown.
If the object has a type library, you can access the custom interface through its VTable layout, which you can get using the... more 

Marshaling Data 

For out-of-process and remote servers, you must consider how COM marshals data outside the current process. You can provide marshaling:

• Automatically, using the IDispatch interface.
• Automatically, by creating a type library with your server and marking the interface with the OLE Automation flag. COM knows how to marshal all the Automation-compatible types in the type library and can set up the proxies and stubs for you. Some type restrictions apply to enable automatic marshaling.
• Manually by implementing all the methods of the IMarshal interface. This is called custom marshaling.

Registering a COM Object 

You can register your server object as an in-process or an out-of-process server. For more information on the server types, see In-process.  

Testing and Debugging the Application 

Once you have created a COM server application, you will want to test it before you deploy it.