| Online Eiffel Documentation

EiffelStudio

# Access Type

Regardless of its location, a COM components can be accessed either directly through interface's virtual table or through OLE Automation.

## Automation

Accessing a COM component through Automation means using a well known interface to access to a group of methods and properties. This interface is called IDispatch, and it includes the method invoke that allows to call a method, set or get a property on the Automation server. One advantage of that approach is that the interface has a known virtual table layout. As a result, Windows can include a built-in marshaler for that interface (See Marshaling for information on what a marshaler is). The supported types (known as Automation types) and their Eiffel equivalents are listed in the following table:

COM Type | Eiffel equivalent | Description
VARIANT_BOOL | BOOLEAN | Standard boolean
unsigned char | CHARACTER | Standard character
double | DOUBLE | Standard double
float | REAL | 2 bytes real
int | INTEGER | Standard integer
long | INTEGER | Standard integer
short | INTEGER | 2 bytes integer
BSTR | STRING | Standard string
CURRENCY | ECOM_CURRENCY | Currency value
DATE | DATE_TIME | Standard date
SCODE | INTEGER | Return status
Interface IDispatch * | ECOM_INTERFACE | Automation interface
Interface IUnknown * | ECOM_INTERFACE | Generic interface
dispinterface | ECOM_INTERFACE | Automation interface
Coclass Typename | TYPE_NAME | Component main class
SAFEARRAY(TypeName) | ECOM_ARRAY [TypeName] | Array
TypeName* | CELL [TypeName] | Pointer to type
VARIANT | ECOM_VARIANT | Variant value
enum | INTEGER | Enumeration
Decimal | ECOM_DECIMAL | Decimal value

The other advantage is a more dynamic discovery of the methods and properties of a component at runtime. Indeed the IDispatch interface also includes methods to check whether a method or property is available and, in that case, get its identifier. This process is called late binding and allows component to discover at runtime what are other components functionality.

This approach has also a lot of drawbacks: first, late binding is not an efficient way of calling a function on an interface since its identifier must first be requested and then the function called. That's two round trips which can be expensive in a distributed environment. Second, since the marshaler is built-in, it has to know in advance all the possible types that a function can accept to be able to marshal the corresponding data. There are consequently a limitation on the number of types that one can use in signatures of functions on an Automation compatible interface. The set of available types is called Variant and cover most of the standard types. It does not allow however the passing of complex user defined data types. For these reasons Automation is mostly used in scripting environments (where speed is not an important factor) to accomplish simple tasks.

## Direct Access

Direct interface access is the preferred way to access remote servers where speed becomes a concern and data types are specific to the application. The first interface pointer on the component is obtained through the class object (see Class Object ). Other interfaces on the component are obtained by calling the QueryInterface function.

As information on any interface cannot be accessed dynamically, the description of the interfaces must be provided to tools that need to handle the components such as the EiffelCOM wizard. The official way of describing components and interfaces is through IDL. Once an IDL file has been written to describe a component it can be compiled with MIDL to generate both a type library and the code for the marshaller specific to that interface.

## EiffelCOM

The idea in EiffelCOM is the way a component is accessed is implementation detail that the user should not have to deal with. Of course he should be able to choose what kind of access he wants to use but this choice should have no impact on the design of the Eiffel system itself. For that reason, the Eiffel code generated by the wizard follows the same architecture independently of the choice made for interface access and marshalling. The difference lies in the runtime where the actual calls to the components are implemented.

See Also
EiffelCOM wizard
EiffelCOM library
Introduction
Generalities
COM Interfaces
Coclasses
Component Location
Deeper into COM