IMAPIFormMgr::IsInConflict
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.
Determines whether a form can handle its own message conflicts. A message is in conflict if it has been simultaneously edited by more than one user. This can happen to messages in public folders.
HRESULT IsInConflict(
ULONG ulMessageFlags,
ULONG ulMessageStatus,
LPCSTR szMessageClass LPMAPIFOLDER pFolderFocus
);
Parameters
ulMessageFlags
[in] A pointer to a bitmask of flags copied from the PR_MESSAGE_FLAGS (PidTagMessageFlags) property of a message that indicates the current state of the message.ulMessageStatus
[in] A bitmask of client-defined or provider-defined flags copied from the PR_MSG_STATUS (PidTagMessageStatus) property of a message that provides additional information about the state of the message.szMessageClass
[in] A string that names the message's message class.pFolderFocus
[in] A pointer to the folder that contains the message. The pFolderFocus parameter can be NULL if such a folder does not exist (for example, if the message is embedded in another message).
Return Value
S_OK
The form does not handle its own message conflicts.S_FALSE
The form handles its own message conflicts, or the message for which information was passed is not in conflict.
Remarks
Form viewers call the IMAPIFormMgr::IsInConflict method to discover whether a particular form does not handle its own message conflicts. IsInConflict checks the bitmasks in the ulMessageFlags and ulMessageStatus parameters for the presence of a conflict flag. If a conflict flag is set, IsInConflict resolves the message class passed in the szMessageClass parameter and returns S_OK if the form does not handle its own conflicts. IsInConflict returns S_FALSE if the form handles its own conflicts.
A form that does not handle its own conflicts must be opened by using the IMAPIFormMgr::LoadForm method and cannot reuse an existing form object.
Notes to Callers
Client applications typically have to deal with conflicts when the applications move from one message to the next or previous message in a folder. If a message is in conflict, but the form server for that message can handle conflicts, the client application should execute its usual code for displaying the next or previous message. If the form server cannot handle conflicts, the client application should continue as if it was unaware of the message class of the next or previous message.
See Also
Reference
IMAPIFormAdviseSink::OnActivateNext
PidTagMessageFlags Canonical Property