Edit

message attribute

  • Article

The [message] attribute indicates that the remote procedure call is to be treated as a message from the client to the server.

[message, optional-attribute-list] void function-name(
    [in, optional-parameter-attributes] param-name,. . .);

Parameters

optional-attribute-list

Other attributes that apply to the function. Only the [local], [nocode], [code], and [optimize] attributes may be used with the [message] attribute.

function-name

The name of the function as defined in the IDL file.

optional-parameter-attributes

Zero or more MIDL attributes that will be applied to the parameter.

param-name

The name of the parameter as defined in the IDL file.

Remarks

As messages from the client, remote procedure calls with the [message] attribute are delivered to the server asynchronously over the ncadg_mq message-queuing transport. You can indicate synchronous-mode messaging by specifying the ncadg_mq transport protocol without using the [message] attribute.

By specifying asynchronous-mode messaging, the [message] attribute allows the client to make the remote procedure call and return immediately, even when the server application is not responding. If the target server is not available, the call will be stored until the server becomes available.

In addition, asynchronous-mode messaging lets you control message-queue properties of the receive queue for the server. See RpcBindingSetOption for more information on selecting quality of service, call priority, and call lifetime for the server process.

The following restrictions also apply to the [message] attribute:

  • Microsoft Message Queuing must be implemented in the client and server systems and the systems must be visible to each other as determined by the scope of the message queue installation.
  • The binding must use well-known endpoints and the ncadg_mq transport protocol.
  • The function cannot contain output parameters or a return type other than void. Note that the latter restriction makes the [message] attribute unsuitable for COM (object) interface methods, at this time. The next release of MIDL will permit [message] functions to return error_status_t or HRESULT.
  • Any interface that contains at least one [message] call must be registered by calling RpcServerRegisterIf or RpcServerRegisterIfEx before calling RpcServerUseProtseqEpEx(ncadg_mq). Otherwise, calls that were waiting on the queue for the server will be read before the interface is registered, and the calls will fail.

Examples

[message] void DisplayString(
    [in, string] char * p1);
 
[message] void VarDataArray(
    [in, size_is(iSize)] ARRAY_TYPE lpMyArray,
    [in] int iSize,
    [in] unsigned long ulChksum);

See also

code

local

ncadg_mq

nocode

optimize

RPC Message Queuing

RpcBindingSetOption

RpcBindingInqOption

void