call_as (attribut)

Article
06/13/2023

L’attribut [call_as] vous permet de mapper une fonction qui ne peut pas être appelée à distance à une fonction distante.

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

Paramètres

local-proc: Spécifie une routine définie par l’opération.
operation-attribute-list: Spécifie un ou plusieurs attributs qui s’appliquent à l’opération. Séparez plusieurs attributs par des virgules.
nom_opération: Spécifie l’opération nommée présentée à l’application.

Notes

La possibilité de mapper une fonction qui ne peut pas être appelée à distance à une fonction distante est particulièrement utile dans les interfaces qui ont de nombreux types de paramètres qui ne peuvent pas être transmis sur le réseau. Au lieu d’utiliser de nombreux types [represent_as] et [transmit_as], vous pouvez combiner toutes les conversions à l’aide de [ call_as] routines. Vous fournissez les deux routines [call_as] (côté client et côté serveur) pour lier la routine entre les appels d’application et les appels distants.

L’attribut [call_as] peut être utilisé pour les interfaces objet. Dans ce cas, la définition d’interface peut être utilisée pour les appels locaux ainsi que pour les appels distants, car [call_as] permet à une interface inaccessible à distance d’être mappée en toute transparence à une interface distante. L’attribut [call_as] ne peut pas être utilisé en mode /osf.

Par exemple, supposons que la routine f1 dans l’interface objet IFace nécessite de nombreuses conversions entre les appels utilisateur et ce qui est réellement transmis. Les exemples suivants décrivent les fichiers IDL et ACF pour l’interface IFace :

Dans le fichier IDL pour l’interface IFace :

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

Dans ACF pour l’interface IFace :

[call_as( f1 )] Remf1();

Le fichier d’en-tête généré définit l’interface à l’aide de la définition de f1, mais fournit également des stubs pour Remf1.

Le compilateur MIDL génère la table virtuelle suivante dans le fichier d’en-tête pour l’interface IFace :

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

Le proxy côté client aurait alors un proxy MIDL classique généré pour Remf1, tandis que le stub côté serveur pour Remf1 serait le même que le stub typique généré par MIDL :

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

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

    // Other function code.
}

Ensuite, les deux routines de liaison [call_as] (côté client et côté serveur) doivent être codées manuellement :

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.
    }

Pour les interfaces d’objet, il s’agit des prototypes des routines de liaison.

Côté client :

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

Côté serveur :

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

Pour les interfaces sans objet, il s’agit des prototypes des routines de liaison.