文档锁
文档锁定协议
若要请求基于 ACP 的应用程序的文档锁定，TSF 管理器调用 ITextStoreACP：：RequestLock。 对于基于定位点的应用程序，TSF 管理器调用 ITextStoreAnchor：：RequestLock。 应用程序通过调用 ITextStoreACPSink：：OnLockGranted (基于 ACP 的应用程序) 或 ITextStoreAnchorSink：：OnLockGranted (RequestLock 内的基于定位点的应用程序) 来授予文档锁定。 锁仅在 OnLockGranted 调用期间有效。 当 OnLockGranted 返回时，文档被视为已解锁。
文档锁的类型
有两种类型的文档锁：只读和读/写。 只读锁使管理器能够读取文本，但无法修改或插入文本。 读/写锁使管理器能够读取、修改和插入文本。 通过在 dwFlags 中指定TS_LF_READ来请求只读锁。 通过在 dwFlags 中指定TS_LF_READWRITE来请求读/写锁。
异步和同步请求
锁请求可以是同步的，也可以是异步的。 管理器通过使用 dwFlags 中的 TS_LF_SYNC 标志请求同步锁。 如果此标志不存在，则请求是异步的。
授予锁
调用 RequestLock 时，应用程序必须确定文档当前是否已锁定。 如果文档未锁定，并且不存在其他拒绝锁定的原因，则应用程序应将 phrSession 设置为 S_OK并返回S_OK。
如果文档已锁定且锁定请求是同步的，则应用程序应将 phrSession 设置为 TS_E_SYNCHRONOUS并返回S_OK。 这表示无法授予同步请求。
如果文档已锁定且锁定请求是异步的，则应用程序应将请求排队，将 phrSession 设置为TS_S_ASYNC并返回S_OK。 当文档可用时，应用程序应从队列中删除请求并调用 OnLockGranted。 锁请求的此队列是可选的;应用程序必须支持一种方案。 如果文档具有只读锁，则新锁请求是可读/写的，并且请求是异步的，则应用程序已调用 OnLockGranted ，从而导致对 RequestLock 的可重新调用。 应用程序应将 phrSession 设置为 TS_S_ASYNC 并返回S_OK。 对 OnLockGranted 的调用返回后，应用程序应使用 TS_LF_READWRITE 再次调用 OnLockGranted 来处理升级请求。
锁定强制实施
在允许访问文档之前，应用程序必须确保存在正确类型的锁。 例如，在允许 ITextStoreACP：：GetText 或 ITextStoreAnchor：：GetText 继续之前，应用程序应验证文档是否至少具有只读锁。 如果不存在正确的锁，应用程序应返回TF_E_NOLOCK。
相关主题
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈