3.1.4.2.16 ApiGetResourceType (Opnum 15)

(Protocol Version 3) The ApiGetResourceType method returns the name of the resource type of the specified resource.

The server SHOULD accept an ApiGetResourceType request if its protocol server state is read-only and MUST accept the request for processing if it is in the read/write state, as specified in section 3.1.1.

The server SHOULD accept an ApiGetResourceType request if the access level associated with the hResource context handle is at least "Read" (section 3.1.4).

 error_status_t ApiGetResourceType(
   [in] HRES_RPC hResource,
   [out, string] LPWSTR *lpszResourceType,
   [out] error_status_t *rpc_status
 );

hResource: An HRES_RPC context handle that was obtained in a previous ApiOpenResource, ApiOpenResourceEx, or ApiCreateResource method call.

lpszResourceType: The address of a pointer where the server MUST write, upon successful completion of this method, the address of a Unicode string buffer containing the name of the resource type of the specified resource. The server MUST allocate as much memory as is required to return the resource type. If the method fails, this parameter MUST be ignored.

rpc_status: A 32-bit integer used to indicate success or failure. The RPC runtime MUST indicate, by writing to this parameter, whether it succeeded in executing this method on the server. The encoding of the value passed in this parameter MUST conform to encoding for  comm_status and fault_status, as specified in Appendix E of [C706].

Return Values: The method MUST return the following error codes for the specified conditions.

Return value/code	Description
0x00000000 ERROR_SUCCESS	Success.
0x00000006 ERROR_INVALID_HANDLE	The data that is pointed to by the hResource parameter does not represent a valid HRES_RPC context handle.

For any other condition, this method MUST return a value that is not one of the values listed in the preceding table. The client MUST behave in one consistent, identical manner for all values that are not listed in the preceding table. The client SHOULD treat errors specified in section 3.2.4.6 as recoverable errors and initiate the reconnect procedure as specified in section 3.2.4.6.