call _ as-Attribut

Mit [ dem Attribut call _ as ] können Sie einer Remotefunktion eine Funktion zuordnen, die nicht remote aufgerufen werden kann.

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

Parameter

local-proc

Gibt eine vorgangsdefinierte Routine an.

operation-attribute-list

Gibt ein oder mehrere Attribute an, die für den Vorgang gelten. Trennen Sie mehrere Attribute durch Kommas.

operation-name

Gibt den benannten Vorgang an, der der Anwendung präsentiert wird.

Bemerkungen

Die Möglichkeit, eine Funktion, die nicht remote aufgerufen werden kann, einer Remotefunktion zu zuordnen, ist besonders hilfreich bei Schnittstellen mit zahlreichen Parametertypen, die nicht über das Netzwerk übertragen werden können. Anstatt viele Als- und Übertragungstypen zu verwenden, können Sie alle Konvertierungen kombinieren, indem [ _ Sie ] als [ _ ] [ _ ] Routinen aufrufen. Sie stellen die beiden [ _ Aufrufe als ] Routinen (client- und serverseitig) zur Bindung der Routine zwischen den Anwendungsaufrufen und den Remoteaufrufen zur Anwendung.

Der [ Aufruf _ als ] -Attribut kann für Objektschnittstellen verwendet werden. In diesem Fall kann die Schnittstellendefinition für lokale Aufrufe sowie für Remoteaufrufe verwendet werden, da aufruf as ermöglicht, dass eine Schnittstelle, [ _ ] auf die nicht remote zugegriffen werden kann, transparent einer Remoteschnittstelle zugeordnet werden kann. Der [ Aufruf _ als ] -Attribut kann nicht im /osf-Modus verwendet werden.

Angenommen, die Routine f1 in der Objektschnittstelle IFace erfordert zahlreiche Konvertierungen zwischen den Benutzeraufrufen und dem, was tatsächlich übertragen wird. In den folgenden Beispielen werden die IDL- und ACF-Dateien für die Schnittstelle IFace beschrieben:

In der IDL-Datei für die Schnittstelle IFace:

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

In der ACF für Schnittstelle IFace:

[call_as( f1 )] Remf1();

Dies bewirkt, dass die generierte Headerdatei die Schnittstelle mithilfe der Definition von f1 definiert, stellt jedoch auch Stubs für Remf1 bereit.

Der MIDL-Compiler generiert die folgende VTable in der Headerdatei für die Schnittstelle IFace:

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

Der clientseitige Proxy würde dann über einen typischen MIDL-generierten Proxy für Remf1 verfügen, während der serverseitige Stub für Remf1 mit dem typischen MIDL-generierten Stub identisch wäre:

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

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

    // Other function code.
}

Anschließend müssen die beiden [ _ Aufrufe ] als Bindungsroutinen (client- und serverseitig) manuell codiert werden:

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

Bei Objektschnittstellen sind dies die Prototypen für die Bindungsroutinen.

Für die Clientseite:

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

Auf Serverseite:

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

Bei Nicht-Objektschnittstellen sind dies die Prototypen für die Bindungsroutinen.

Für die Clientseite:

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

Auf Serverseite:

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

Weitere Informationen

/osf

darstellen _ als

übertragen _ als