Cocoaからのライブ変換(LiveConversion)の変更と監視その2
進捗があった。非公開プロトコルを適応することで、ライブ変換を制御できる。
変更と監視は出来ない。TextFieldに入力中にライブ変換を一時的に無効にすることができるだけ。
プロトコルNSTextInputClient_IncrementalSearch
NTextViewのサブクラスで、NSTextInputClient_IncrementalSearchに適合しているクラスではライブ変換は無効になる。
ヘッダは以下のようになっている。
@class NSEvent;
@protocol NSTextInputClient_IncrementalSearch
- (BOOL)wouldHandleEvent:(NSEvent *)arg1;
- (unsigned long long)incrementalSearchClientGeometry;
@end
メソッドそれぞれの詳細は不明だが、wouldHandleEventではfalseを返し、incrementalSearchClientGeometryでは0を返すことで動作した。
incrementalSearchClientGeometryで0以外の場合は、変換候補のWindowが表示されなかった。
field editor
NSWindow上にNSTextFieldを複数配置した場合を考えます。この時、Textの編集が出来るNSTextFieldは常に、その内のどれか一つです。その他のNSTextFieldは、表示されているだけです。
この特徴を特性を利用して、Cocoaフレームワークでは、NSTextFieldは表示だけを行い、編集するときは同じ場所で別のオブジェクト(NSTextView)に任せるという方式を採用しています。
この別のオブジェクトは、NSWindow上のNSTextFieldで共有されており、それをField Editorと呼びます。
昔々のNextStepの時代では、CPUのパワーは今よりも貴重でした。Cocoaフレームワークには、その時代の設計の名残があります。field editorもその名残です。
このことは、先ほどのライブ変換を制御と関係があります。ライブ変換を制御するには、NSTextFieldのサブクラスだけではなくて、NSTextInputClient_IncrementalSearchに適応したNSTextViewのサブクラスを作る必要があるのです。
さらには、上記の text field を挿げ替えて、特定のTextFieldの時だけ、こちらが指定した custom field editor を使用するように指示する必要があります。
この仕組みは、以下のようになります。
class WindowController: NSWindowController, NSWindowDelegate
{
.
.
.
@objc dynamic var custumFieldEditor: MINTLIncrementalSearchFieldEditor? = nil
public func windowWillReturnFieldEditor(_ sender: NSWindow, to client: Any?) -> Any?
{
// カスタムのfieldEditorを使う
if client is MINTLIncrementalSearchField?
{
if self.custumFieldEditor == nil
{
self.custumFieldEditor = MINTLIncrementalSearchFieldEditor()
self.custumFieldEditor!.isFieldEditor = true
}
return self.custumFieldEditor
}
// デフォルトのfieldEditorを使う
return nil
}
.
.
.
}