call_as (atributo)
El atributo [call_as] permite asignar una función a la que no se puede llamar de forma remota a una función remota.
[call_as (local-proc), [ , operation-attribute-list ] ] operation-name ;
Parámetros
-
local-proc
-
Especifica una rutina definida por la operación.
-
operation-attribute-list
-
Especifica uno o varios atributos que se aplican a la operación. Separe varios atributos con comas.
-
operation-name
-
Especifica la operación con nombre presentada a la aplicación.
Comentarios
La capacidad de asignar una función a la que no se puede llamar de forma remota a una función remota es especialmente útil en las interfaces que tienen numerosos tipos de parámetros que no se pueden transmitir a través de la red. En lugar de usar muchos tipos [represent_as] y [transmit_as], puede combinar todas las conversiones mediante las rutinas [call_as]. Proporcione las dos rutinas [call_as] (lado cliente y servidor) para enlazar la rutina entre las llamadas de aplicación y las llamadas remotas.
El atributo [call_as] se puede usar para interfaces de objeto. En este caso, la definición de interfaz se puede usar para llamadas locales, así como llamadas remotas porque [call_as] permite que una interfaz a la que no se pueda acceder de forma remota se asigne de forma transparente a una interfaz remota. El atributo [call_as] no se puede usar con el modo /osf .
Por ejemplo, supongamos que la rutina f1 en la interfaz de objeto IFace requiere numerosas conversiones entre las llamadas de usuario y lo que realmente se transmite. En los ejemplos siguientes se describen los archivos IDL y ACF para la interfaz IFace:
En el archivo IDL de la interfaz IFace:
[local] HRESULT f1 ( <users parameter list> )
[call_as( f1 )] long Remf1( <remote parameter list> );
En el ACF para la interfaz IFace:
[call_as( f1 )] Remf1();
Esto hace que el archivo de encabezado generado defina la interfaz mediante la definición de f1, pero también proporciona códigos auxiliares para Remf1.
El compilador MIDL generará la siguiente tabla virtual en el archivo de encabezado para IFace de interfaz:
struct IFace_vtable
{
HRESULT ( * f1) ( <users parameter list> );
/* Other vtable functions. */
};
Después, el proxy del lado cliente tendría un proxy típico generado por MIDL para Remf1, mientras que el código auxiliar del lado servidor para Remf1 sería el mismo que el código auxiliar generado por MIDL típico:
HRESULT IFace_Remf1_Stub ( <parameter list> )
{
// Other function code.
/* instead of IFace_f1 */
invoke IFace_f1_Stub ( <remote parameter list> );
// Other function code.
}
A continuación, las dos rutinas de enlace [call_as] (lado cliente y servidor) deben codificarse 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.
}
En el caso de las interfaces de objeto, estos son los prototipos de las rutinas de enlace.
Para el lado cliente:
<local_return_type> <interface>_<local_routine>_proxy(
<local_parameter_list> );
Para el lado servidor:
<remote_return_type> <interface>_<local_routine>_stub(
<remote_parameter_list> );
En el caso de las interfaces que no son objetos, estos son los prototipos de las rutinas de enlace.
Para el lado cliente:
<local_return_type> <local_routine> ( <local_parameter_list> );
Para el lado servidor:
<local_return_type> <interface>_v<maj>_<min>_<local_routine> (
<remote_parameter_list> );
Consulte también