コンテキストの編集
アプリケーション
編集コンテキストを作成するために、アプリケーションは ITfDocumentMgr::CreateContext を呼び出します。
Text Services
テキスト サービスでは、多くの場合、現在アクティブな編集コンテキストが使用されます。 現在アクティブな編集コンテキストは、作業中のドキュメント マネージャーのスタックの上部にある編集コンテキストです。 現在アクティブなコンテキストを取得するために、テキスト サービスは ITfThreadMgr::GetFocus を呼び出して作業中のドキュメント マネージャーを取得し、 ITfDocumentMgr::GetTop を呼び出して、スタックの上部にある編集コンテキストを取得します。
場合によっては、テキスト サービスに独自の編集コンテキストが必要になります。 編集コンテキストを作成するために、テキスト サービスは ITfDocumentMgr::CreateContext を呼び出します。
Cookie の編集
ITfRange::SetText などの多くのメソッドでは、読み取り専用または読み取り/書き込みドキュメント ロックを持つ編集コンテキストを識別する方法が必要です。 ドキュメント ロックは、TSF マネージャーとアプリケーションの間のネゴシエーションによって取得されます。 テキスト サービスは、このネゴシエーションを直接実行できません。 テキスト サービスは、特定のコンテキストと読み取り専用または読み取り/書き込みアクセス権を持つ 編集セッション を要求することによってのみロックを取得できます。 編集セッションが許可されると、テキスト サービスには、要求されたアクセス権を持つ編集コンテキストを識別する編集 Cookie が提供されます。 その後、この Cookie が メソッドに渡され、適切なアクセス権を持つ編集コンテキストが識別されます。
ITfDocumentMgr::CreateContext では、コンテキスト作成者に編集 Cookie も提供されます。 この Cookie には読み取り専用アクセス権があり、アクセス レベルを変更する方法はありません。 実際、TSF マネージャーは、この編集 Cookie のドキュメント ロックをネゴシエートしません。 Cookie は内部的に読み取り専用としてマークされていますが、ドキュメントは実際にはロックされていません。 たとえば、コンテキスト作成者が ITfDocumentMgr::CreateContext によって返される編集 Cookie を使用して ITfContext::GetSelection を呼び出すと、アプリケーションの ITextStoreACP::GetSelection または ITextStoreAnchor::GetSelection が呼び出されます。 選択を取得する前に、アプリケーションはドキュメント ロックが存在するかどうかを判断します。 ロックが存在しないため、アプリケーションはTS_E_NOLOCKで失敗します。 つまり、アプリケーションがこの Cookie を使用してメソッドを呼び出し、その結果、アプリケーションのテキスト ストア メソッドの 1 つが呼び出される場合、アプリケーションは実際にはドキュメント ロックを持たないため、内部的にこのケースを処理する必要があります。
コンテキスト作成者が読み取り/書き込みアクセス権を持つ編集 Cookie を必要とする場合は、独自の編集セッションを確立する必要があります。
関連トピック