Collapse the table of content
Expand the table of content
Important This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer


This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Calls an internal function to check the parameters client applications have passed to service providers.

Header file:


Implemented by:


Called by:

Service providers

HRESULT ValidateParms(
  METHODS eMethod,
  LPVOID First


[in] Specifies, by enumeration, the method to validate.


[in] Pointer to the first argument on the stack.


All of the parameters are valid.


One or more of the parameters are not valid.

Parameters passed between MAPI and service providers are assumed to be correct and undergo only debug validation with the CheckParms macro. Providers should check all parameters passed in by client applications, but clients should assume that MAPI and provider parameters are correct. Use the HR_FAILED macro to test return values.

ValidateParms is called differently depending on whether the calling code is C or C++. C++ passes an implicit parameter known as this to each method call, which becomes explicit in C and is the address of the object. The first parameter, eMethod, is an enumerator made from the interface and method being validated and tells what parameters to expect to find on the stack. The second parameter is different for C and C++. In C++ it is called First, and it is the first parameter to the method being validated. The second parameter for the C language, ppThis, is the address of the first parameter to the method which is always an object pointer. In both cases, the second parameter gives the address of the beginning of the method's parameter list, and based on eMethod, moves down the stack and validates the parameters.

Providers implementing common interfaces such as IMAPITable and IMAPIProp should always check parameters using the ValidateParms function in order to make sure consistency across all providers. Additional parameter validation functions have been defined for some complex parameter types to be used instead as appropriate. See the reference topics for the following functions:











Inherited methods use the same parameter validation as the interface from which they inherit. For example, the parameter checking for IMessage and IMAPIProp should be the same.

© 2015 Microsoft