Dokumentsperren
Das Dokumentsperrprotokoll
Um eine Dokumentsperre für ACP-basierte Anwendungen anzufordern, ruft der TSF-Manager ITextStoreACP::RequestLockauf. Für ankerbasierte Anwendungen ruft der TSF-Manager ITextStoreAnchor::RequestLockauf. Die Anwendung gewährt die Dokumentsperre durch Aufrufen ITextStoreACPSink::OnLockGranted (ACP-basierte Anwendungen) oder ITextStoreAnchorSink::OnLockGranted (ankerbasierte Anwendungen) innerhalb RequestLock. Die Sperre ist nur während des OnLockGranted Anruf gültig. Wenn OnLockGranted zurückgegeben wird, gilt das Dokument als entsperrt.
Dokumentsperrentypen
Es gibt zwei Arten von Dokumentsperren, schreibgeschützt und lese-/schreibgeschützt. Eine schreibgeschützte Sperre ermöglicht es dem Vorgesetzten, den Text zu lesen, aber er kann keinen Text ändern oder einfügen. Mit einer Lese-/Schreibsperre kann der Manager Text lesen, ändern und einfügen. Eine schreibgeschützte Sperre wird durch Angabe von TS_LF_READ in dwFlagsangefordert. Eine Lese-/Schreibsperre wird angefordert, indem TS_LF_READWRITE in dwFlags-angegeben wird.
Asynchrone und synchrone Anforderungen
Eine Sperranforderung kann synchron oder asynchron sein. Der Manager fordert eine synchrone Sperre mithilfe des TS_LF_SYNC-Flags in dwFlags-an. Wenn dieses Flag nicht vorhanden ist, ist die Anforderung asynchron.
Gewähren der Sperre
Wenn RequestLock- aufgerufen wird, muss die Anwendung ermitteln, ob das Dokument momentan gesperrt ist. Wenn das Dokument nicht gesperrt ist und kein anderer Grund zum Verweigern der Sperre vorhanden ist, sollte die Anwendung phrSession- auf S_OK festlegen und S_OK zurückgeben.
Wenn das Dokument gesperrt ist und die Sperranforderung synchron ist, sollte die Anwendung phrSession- auf TS_E_SYNCHRONOUS festlegen und S_OK zurückgeben. Dies gibt an, dass eine synchrone Anforderung nicht erteilt werden kann.
Wenn das Dokument gesperrt ist und die Sperranforderung asynchron ist, sollte die Anwendung die Anforderung in die Warteschlange stellen, phrSession auf TS_S_ASYNC festlegen und S_OK zurückgeben. Wenn das Dokument verfügbar wird, sollte die Anwendung die Anforderung aus der Warteschlange entfernen und OnLockGrantedaufrufen. Diese Warteschlange von Sperranforderungen ist optional; Es gibt ein Szenario, das eine Anwendung unterstützen muss. Wenn das Dokument über eine schreibgeschützte Sperre verfügt, ist die neue Sperranforderung lese-/schreibgeschützt, und die Anforderung ist asynchron, die Anwendung hat OnLockGranted aufgerufen, was zu einem erneuten Aufruf von RequestLockgeführt hat. Die Anwendung sollte phrSession- auf TS_S_ASYNC festlegen und S_OK zurückgeben. Nachdem der Aufruf von OnLockGranted zurückgegeben wurde, sollte die Anwendung die Upgradeanforderung verarbeiten, indem sie OnLockGranted erneut mit TS_LF_READWRITE aufruft.
Sperren der Erzwingung
Die Anwendung muss sicherstellen, dass der richtige Sperrtyp vorhanden ist, bevor der Zugriff auf das Dokument zugelassen wird. Die Anwendung sollte beispielsweise überprüfen, ob ein Dokument mindestens über eine schreibgeschützte Sperre verfügt, bevor ITextStoreACP::GetText oder ITextStoreAnchor::GetText fortgesetzt werden kann. Wenn die richtige Sperre nicht vorhanden ist, sollte die Anwendung TF_E_NOLOCK zurückgeben.
Verwandte Themen