This is retired content. 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 content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
A version of this page is also available for

A conflict occurs when an object has changed on both the Windows Mobile device and the desktop since the last synchronization. The conflict is resolved by prompting the user to choose which object to save.

Conflict resolution begins when the service manager calls IReplObjHandler::GetPacketon the Windows Mobile device to send a copy of the object to the desktop. The desktop service manager then calls IReplObjHandler::SetPacketto create a temporary object. During both the Windows Mobile device and the desktop call, the service manager passes RSF_CONFLICT_OBJECT in REPLSETUP::dwFlags.

The following illustration shows the call sequence for conflict resolution.

After the service manager receives the data from the Windows Mobile device, it calls IReplStore::GetConflictInfoand passes a handle to both the original desktop object and the temporary device object. Next, the desktop provider fills in the CONFINFOstructure to customize the description text displayed in a standard Conflict Resolutiondialog box, which is supplied by the service manager.

The following code example shows how to implement IReplStore::GetConflictInfo.

Copy Code
STDMETHODIMP CStore::GetConflictInfo
	PCONFINFO pConfInfo  // pointer to a CONFINFO structure
   // Verify that you have the right version of OBJUIDATA.
   if (pConfInfo->cbStruct != sizeof (CONFINFO))
	 return E_INVALIDARG;

   // Copy "Stock" to szLocalName and szRemoteName. You can use
	// own local and remote object names to replace "Stock".
   lstrcpy (pConfInfo->szLocalName,  "Stock");
   lstrcpy (pConfInfo->szRemoteName, "Stock");

   CItem *pLocalItem  = (CItem*)pConfInfo->hLocalItem;
   CItem *pRemoteItem = (CItem*)pConfInfo->hRemoteItem;

   // Find the local object, then the remote object.
	// pLocalObject  points to the local  object.
   // pRemoteObject points to the remote object.

   // If both the local and remote objects are found
   if (pLocalObject && pRemoteObject)
	// Compare local and remote objects.
	// If identical, return RERR_IGNORE.

   // if local object  found
   if (pLocalObject)
	// Store information for local object in

   // if remote object found
   if (pRemoteObject)
	// Store information for remote object in

   return NOERROR;

If the desktop provider cannot write a temporary object on the desktop, it can save the packets in memory and return HREPLITEMwith a pointer to the memory location. In this case, the desktop provider must implement this handle in all IReplStoremethods that accept an HREPLITEMhandle, such as CopyObjector FreeObject. When the service manager calls IReplStore::GetConflictInfo, the handle becomes CONFINFO::hRemoteItem. The desktop provider then can extract descriptive text from the handle and save it in CONFINFO.

The Conflict Resolutiondialog box prompts the user to choose one of the following actions:

  • Replace the desktop object with the modified device object.

    The service manager marks the desktop object as up-to-date and the device object as changed. This ensures that the device object is transferred to the desktop during the next synchronization.

  • Replace the device object with the modified device object.

    The service manager marks the device object as up-to-date.

  • Leave the information item unresolved.

    The information type is not synchronized. This option will allow the service manager to handle the resolution.

In either case, the service manager calls IReplObjHandler::DeleteObjectto delete the temporary object.

Conflict situations do not always require a Conflict Resolutiondialog box. The following table describes special error values that IReplStore::GetConflictInfocan return to resolve the conflict automatically.

Value Action


The desktop provider compares two handles in CONFINFO, determines that they are identical, and takes no action.


The service manager determines that the desktop object represented by a handle is already deleted and deletes the device object accordingly.


The service manager resolves the conflict by deleting a desktop object instead of allowing the desktop provider to delete the object.

See Also