Atributo call_as

O atributo [call_as] permite mapear uma função que não pode ser chamada remotamente para uma função remota.

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

Parâmetros

local-proc

Especifica uma rotina definida pela operação.

operation-attribute-list

Especifica um ou mais atributos que se aplicam à operação. Separe vários atributos com vírgulas.

operation-name

Especifica a operação nomeada apresentada ao aplicativo.

Comentários

A capacidade de mapear uma função que não pode ser chamada remotamente para uma função remota é particularmente útil em interfaces que têm vários tipos de parâmetro que não podem ser transmitidos pela rede. Em vez de usar muitos tipos [represent_as] e [transmit_as] , você pode combinar todas as conversões usando rotinas [call_as ]. Você fornece as duas rotinas [call_as] (lado do cliente e do servidor) para associar a rotina entre as chamadas de aplicativo e as chamadas remotas.

O atributo [call_as] pode ser usado para interfaces de objeto. Nesse caso, a definição de interface pode ser usada para chamadas locais, bem como chamadas remotas porque [call_as] permite que uma interface que não pode ser acessada remotamente seja mapeada de forma transparente para uma interface remota. O atributo [call_as] não pode ser usado com o modo /osf .

Por exemplo, suponha que a rotina f1 na interface de objeto IFace exija várias conversões entre as chamadas do usuário e o que é realmente transmitido. Os exemplos a seguir descrevem os arquivos IDL e ACF para a interface IFace:

No arquivo IDL da interface IFace:

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

No ACF para interface IFace:

[call_as( f1 )] Remf1();

Isso faz com que o arquivo de cabeçalho gerado defina a interface usando a definição de f1, mas também fornece stubs para Remf1.

O compilador MIDL gerará a seguinte Vtable no arquivo de cabeçalho para a interface IFace:

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

O proxy do lado do cliente teria um proxy típico gerado por MIDL para Remf1, enquanto o stub do lado do servidor para Remf1 seria o mesmo que o stub típico gerado por MIDL:

HRESULT IFace_Remf1_Stub ( <parameter list> ) 
{ 
    // Other function code.

    /* instead of IFace_f1 */
    invoke IFace_f1_Stub ( <remote parameter list> ); 

    // Other function code.
}

Em seguida, as duas rotinas de vínculo [call_as] (lado do cliente e do lado do servidor) devem ser codificadas manualmente:

HRESULT f1_Proxy ( <users parameter list> ) 
{ 
    // Other function code.

    Remf1_Proxy ( <remote parameter list> ); 

    // Other function code.
} 
 
long IFace_f1_Stub ( <remote parameter list> ) 
{ 
    // Other function code.

    IFace_f1 ( <users parameter list> ); 

    // Other function code.
    }

Para interfaces de objeto, esses são os protótipos para as rotinas de vínculo.

Para o lado do cliente:

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

Para o lado do servidor:

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

Para interfaces nonobject, esses são os protótipos para as rotinas de vínculo.

Para o lado do cliente:

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

Para o lado do servidor:

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

Confira também

/Osf

represent_as

transmit_as