19.8.12 Automation View Interface as a Dispatch Interface

   In addition to implementing the Automation View Interface as an Automation Dual Interface, it is also acceptable to map it as a generic Dispatch Interface.

   Note – All views that expose the dual interface must respond to QueryInterface for both the dual interface IID as well as for the non-dual interface IID.

   In this case, the normal methods and attribute accessor/assign methods are not required to have HRESULT return values. Instead, an additional “dispinterface? is defined, which can use the standard OLE dispatcher to dispatch invocations.

   For example, a method declared in a dual interface in ODL as follows:

   HRESULT aMethod([in] <type1> arg1, [out] <type2> arg2,[retval, out] <return type> *val)

   would be declared in ODL in a dispatch interface in the following form:

   <return type> aMethod([in] <type1> arg1, [out] <type2> arg2)

   Using the example from Section 19.2, “Mapping for Interfaces,? on page 19-3:

   interface account

   {// OMG IDL

   attribute float balance;

   readonly attribute string owner;

   void makeLodgement (in float amount, out float

   balance);

   void makeWithdrawal (in float amount, out float

   balance); };

   the corresponding Iaccount interfaces are defined as follows.

   [uuid(e268443e-43d9-3dab-1dbe-f303bbe9642f), oleautomation]dispinterface Daccount: IUnknown {// ODL

   properties:

   [id(0)] float balance;

   [id(i), readonly] BSTR owner;

   methods:

   [id(2)] void makeLodgement([in] float amount,

   [out] float *balance,

   [out, optional]VARIANT OBJ);

   [id(3)] void makeWithdrawal ([in] float amount,

   [out] float *balance,

   [out,optional]VARIANT *excep OBJ);

   };

   The dispatch interface is Daccount. In the example used for mapping object references in Section 19.5, “Mapping for Object References,? on page 19-15, the reference to the Simple interface in the OMG IDL would map to a reference to DMyModule_Simple rather than DIMyModule_Simple. The naming conventions for Dispatch Interfaces (and for their IIDs) exposed by the View are slightly different from Dual Interfaces. See Section 17.7.8, “Naming Conventions for View Components,? on page 17-30 for details.

   The Automation View Interface must correctly respond to a QueryInterface for the specific Dispatch Interface Id (DIID) for that View. By conforming to this requirement, the Automation View can be strongly type-checked. For example, ITypeInfo::Invoke, when handling a parameter that is typed as a pointer to a specific DIID, calls QueryInterface on the object for that DIID to make sure the object is of the required type.

   Pseudo-Automation Interfaces representing CORBA complex types such as structs, unions, exceptions and the other noninterface constructs mapped to dispatch interfaces can also be exposed as nondual dispatch interfaces.