Resolving Conflicts

A version of this page is also available for

Windows Embedded CE 6.0 R3

4/8/2010

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::GetPacket on the Windows Mobile device to send a copy of the object to the desktop. The desktop service manager then calls IReplObjHandler::SetPacket to 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::GetConflictInfo and passes a handle to both the original desktop object and the temporary device object. Next, the desktop provider fills in the CONFINFO structure to customize the description text displayed in a standard Conflict Resolution dialog box, which is supplied by the service manager.

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

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 your
      // 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 pConfInfo->szLocalDesc.

   // if remote object found
   if (pRemoteObject)
      // Store information for remote object in pConfInfo->szRemoteDesc.

   return NOERROR;
}

If the desktop provider cannot write a temporary object on the desktop, it can save the packets in memory and return HREPLITEM with a pointer to the memory location. In this case, the desktop provider must implement this handle in all IReplStore methods that accept an HREPLITEM handle, such as CopyObject or 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 Resolution dialog 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::DeleteObject to delete the temporary object.

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

See Also

Concepts

Sending and Receiving Changed Objects