message

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

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.

Example

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

Remarks

The message attribute indicates that the remote procedure call is to be treated as a "message" from the client to the server. As such, the call is delivered 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.

See Also

RPC Message Queuing, RpcBindingSetOption, RpcBindingInqOption, ncadg_mq