call_as

[call_as (local-proc), [ , operation-attribute-list ] ] operation-name ;

local-proc: Specifies an operation-defined routine.
operation-attribute-list: Specifies one or more attributes that apply to the operation. Separate multiple attributes with commas.
operation-name: Specifies the named operation presented to the application.

Remarks

The call_as attribute enables a nonremotable function to be mapped to a remote function. This is particularly helpful in interfaces that have numerous nonremotable types as parameters. Rather than using many represent_as and transmit_as types, you can combine all the conversions using call_as routines. You supply the two call_as routines (client side and server side) to bind the routine between the application calls and the remote calls. The call_as attribute can be used for object interfaces, where the interface definition can be used for local calls as well as remote calls because it allows a nonremotable interface to be remoted transparently. The call_as attribute cannot be used with /osf mode.

For example, assume that the routine f1 in object interface IFace requires numerous conversions between the user calls and what is actually transmitted. The following examples describe the IDL and ACF files for interface IFace:

In the IDL file for interface IFace:

[local] HRESULT f1 ( <users parameter list> ) 
[call_as( f1 )] long Remf1 ( <remotable parameter list> );

In the ACF for interface IFace:

[call_as( f1 )] Remf1();

This would cause the generated header file to define the interface using the definition of f1, yet it would also provide stubs for Remf1:

Generated Vtable in the header file for interface IFace:

struct IFace_vtable
        { 
        .. 
        HRESULT ( * f1) ( <users parameter list>); 
        .. 
        };

The client-side proxy would then have a typical MIDL-generated proxy for Remf1, while the server side stub for Remf1 would be the same as the typical MIDL-generated stub:

HRESULT IFace_Remf1_Stub ( . . .) 
    { 
    .. 
    invoke IFace_f1_Stub ( <remotable parameter list> )    /* instead 
            of IFace_f1 */ 
    .. 
    }

Then, the two call_as bond routines (client side and server side) must be manually coded:

HRESULT f1_Proxy ( <users parameter list> ) 
    { 
    .. 
    Remf1_Proxy ( <remotable parameter list> ); 
    .. 
    } 
 
long IFace_f1_Stub ( <remotable parameter list> ) 
    { 
    .. 
    IFace_f1 ( <users parameter list> ); 
    .. 
    }

For object interfaces, these are the prototypes for the bond routines.

For client side:

<local_return_type>  <interface>_<local_routine>_proxy 
( <local_parameter_list> );

For server side:

<remote_return_type>  <interface>_<local_routine>_stub 
( <remote_parameter_list> );

For nonobject interfaces, these are the prototypes for the bond routines.

For client side:

<local_return_type>  <local_routine> ( <local_parameter_list> );

For server side:

<local_return_type>  <interface>_v<maj>_<min>_<local_routine> 
( <remote_parameter_list> );

call_as

Remarks

See Also