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 ;
-
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.
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> );