編輯內容
應用程式
若要建立編輯內容，應用程式會呼叫 ITfDocumentMgr：：CreateCoNtext。
文字服務
文字服務通常會使用目前作用中的編輯內容。 目前使用中的編輯內容是使用中檔管理員堆疊頂端的編輯內容。 若要取得目前使用中的內容，文字服務會呼叫 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 的方法，導致呼叫其中一個應用程式的文字存放區方法，則必須在內部處理此案例，因為應用程式實際上不會有檔鎖定。
如果內容建立者需要具有讀取/寫入存取權的編輯 Cookie，則必須建立自己的編輯會話。
相關主題
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應