Dokumentsperren
Das Dokumentsperrprotokoll
Um eine Dokumentsperre für ACP-basierte Anwendungen anzufordern, ruft der TSF-Manager ITextStoreACP::RequestLock auf. Für ankerbasierte Anwendungen ruft der TSF-Manager ITextStoreAnchor::RequestLock auf. Die Anwendung gewährt die Dokumentsperre, indem sie ITextStoreACPSink::OnLockGranted (ACP-basierte Anwendungen) oder ITextStoreAnchorSink::OnLockGranted (ankerbasierte Anwendungen) in RequestLock aufruft. Die Sperre ist nur während des OnLockGranted-Aufrufs gültig. Wenn OnLockGranted zurückgibt , gilt das Dokument als entsperrt.
Arten von Dokumentsperren
Es gibt zwei Arten von Dokumentsperren, schreibgeschützt und Schreib-/Schreibzugriff. Eine schreibgeschützte Sperre ermöglicht es dem Manager, den Text zu lesen, aber er kann keinen Text ändern oder einfügen. Eine Lese-/Schreibsperre ermöglicht dem Manager das Lesen, Ändern und Einfügen von Text. Eine schreibgeschützte Sperre wird angefordert, indem TS_LF_READ in dwFlags angegeben wird. Eine Lese-/Schreibsperre wird angefordert, indem sie TS_LF_READWRITE in dwFlags angeben.
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 derzeit 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 ist, sollte die Anwendung die Anforderung aus der Warteschlange entfernen und OnLockGranted aufrufen. Dieses Warteschlangening von Sperranforderungen ist optional. Es gibt ein Szenario, das eine Anwendung unterstützen muss. Wenn das Dokument über eine schreibgeschützte Sperre verfügt, die neue Sperranforderung lese-/schreibfähig ist und die Anforderung asynchron ist, hat die Anwendung OnLockGranted aufgerufen, was einen erneuten Aufruf von RequestLock verursacht 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 OnLockGranted mit TS_LF_READWRITE erneut aufgerufen wird.
Sperren erzwingen
Die Anwendung muss sicherstellen, dass der richtige Sperrtyp vorhanden ist, bevor der Zugriff auf das Dokument zugelassen wird. Beispielsweise sollte die Anwendung überprüfen, ob ein Dokument mindestens über eine schreibgeschützte Sperre verfügt, bevor ITextStoreACP::GetText oder ITextStoreAnchor::GetText fortgesetzt wird. Wenn die richtige Sperre nicht vorhanden ist, sollte die Anwendung TF_E_NOLOCK zurückgeben.
Zugehörige Themen