Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Description • 12 years ago

MSDN document doesn't mention about this issue:
http://msdn.microsoft.com/en-us/library/ms538441%28v=vs.85%29

However, it seems that it doesn't make sense to block the query when readonly lock is granted.

Actually, ATOK 2012 calls this method with readonly lcok.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 2 • 12 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/cc43a4e4ee95

	Ryan VanderMeulen [:RyanVM]
	Comment 3 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/cc43a4e4ee95

	Yohei Yukawa
	Comment 4 • 12 years ago

Hi,

-> Comment 1
> Actually, ATOK 2012 calls this method with readonly lcok.

Yes. And this behavior looks valid according to the document of ITfInsertAtSelection::InsertTextAtSelection, which is the counterpart of ITextStoreACP::InsertTextAtSelection and used by TIPs like ATOK.

The document of ITfInsertAtSelection::InsertTextAtSelection says:
> TF_IAS_QUERYONLY: The context is not modified, but ppRange is set as if the insert had
>     occurred. Read-only access is sufficient. If this flag is not set, ec must have
>     read/write access. This flag cannot be combined with the TF_IAS_NOQUERY flag.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms628599.aspx

So I believe the attached patch actually fixed the issue and now your text store conforms to the semantics described in the MSDN document for TIPs.

Cheers,