IMAPIFormMgr::IsInConflict

The IMAPIFormMgr::IsInConflict method 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.

Quick Info

See IMAPIFormMgr : IUnknown.

HRESULT IsInConflict(
  ULONG ulMessageFlags,  
  ULONG ulMessageStatus,   
  LPCSTR szMessageClass  
  LPMAPIFOLDER pFolderFocus  
);
 

Parameters

ulMessageFlags

[in] Pointer to a bitmask of flags — copied from the PR_MESSAGE_FLAGS property of a message — that indicates the current state of the message.

ulMessageStatus

[in] Bitmask of client- or provider-defined flags — copied from the PR_MSG_STATUS property of a message — that provides further information on the state of the message.

szMessageClass

[in] String naming the message's message class.

pFolderFocus

[in] Pointer to the folder that contains the message. The pFolderFocus parameter can be NULL if such a folder doesn't exist — for example, in a case where the message is embedded in another message.

Return Values

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 if 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 launched using the IMAPIFormMgr::LoadForm method and cannot reuse an existing form object.

Notes to Callers

Client applications typically have to deal with conflicts when going 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, then the client application should execute its usual code for displaying the next or previous message. If the form server cannot handle conflicts, then the client application should proceed as if it was unaware of the message class of the next or previous message.

See Also

IMAPIFormAdviseSink::OnActivateNext, PR_MESSAGE_FLAGS, PR_MSG_STATUS