When reconciling a document, the briefcase reconciler itself may become an
initiator if it discovers an embedded object of a type that it cannot reconcile.
In this case, the reconciler needs to recursively reconcile each of the embedded
objects and assume all the responsibilities of an initiator.
To carry out the recursion, the briefcase reconciler loads the object and
queries for the appropriate interface. The handler for the object must support the
interface. If any member function of the interface returns the OLE_E_NOTRUNNING
value, the reconciler must run the object in order to carry out the operation.
Because code for embedded objects is not always available, a reconciler must
provide a solution for this condition. For example, the reconciler might include
both old and new versions of the embedded object in the reconciled version.
The reconciler must not attempt to reconcile across links.
The initiator stores the document versions being merged. In many cases, the
initiator has access to the storage of each version and saves the result of
reconciliation using similar storage. Sometimes, however, the initiator may have an
in-memory object for which no persistent version is available. This situation
can occur when a document containing open embedded objects must be reconciled
before being saved. In such cases, the initiator saves the result of the
reconciliation in the version found in memory.
The initiator uses the IPersistStorage
interface to bind (load) the merged version. The initiator uses the IPersistStorage::Load
member function if an initial version has already been created and uses the IPersistStorage::InitNew
member function for the initial version. Once the merged version is loaded,
the initiator uses QueryInterface
to retrieve the address of the IReconcilableObject
interface. This interface gives the initiator access to the storage of the
existing residues and gives it a way to create storage for any new residues. Then
the initiator directs the interface to carry out the reconciliation. The
initiator actually queries for the IPersistFile
interface before IPersistStorage
. If the reconciler supports IPersistFile
, the initiator manipulates the replica through the IPersistFile
rather than IPersistStorage
member functions. This permits reconciliation of files that are not stored as
Once the reconciliation is complete, the initiator can save the merged version
by using the IPersistStorage
interface. During reconciliation, the briefcase reconciler creates residues
as needed and writes their persistent bits to storage. If the merged version is
a stream, the IStorage
interface passed to IPersistStorage::Load
contains a stream named "Contents" with its storage state set to
STATEBITS_FLAT. (You can set the state bits by using the IStorage::Stat
member function.) After the merge, the initiator saves the merged version by
writing the data in an appropriate manner. It should ensure that STATEBITS_FLAT
is set as appropriate for the storage.
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages
- Databases for Amazon shops developers
Amazon Categories Database
Browse Nodes Database