.NET2.0のWM_IME_CHAR処理

　今日公開のPoderosaβ４で、ターミナル内での日本語直接入力を可能にしたのだけども、これは予想以上に難航した。
　そもそも、旧バージョンと同じソースでは動かず、調べたらこんな騒動があったのでとりあえず放置していたものを穿り返してみたのだけど、凄い展開だった。

　以下、解説とも愚痴ともつかぬものを書いてみる。これをGoogle先生が読んでくれれば似たような現象で悩む人へのヒントになるかもしれんので。

　まず、上記の騒動は、
* UserControlではImeModeプロパティの設定を無視してIMEを強制オフにしてしまう。これを回避する方法はない。
* しかも、それは.NET2.0のβ２から正式の2.0になるまでに導入された仕様である。

　というものだ。なんでそういう互換性のない変更をするかね。

　なので、まずは派生元のコントロールをUserControlからただのControlに変更する。これに伴い、フォーカス制御やコントロールの境界線の描画は自前でやる必要が出る。（BorderStyleプロパティはUserControlにはあるがControlにはない）

　ところが話はまだ終わらない。この変更をしてみると、IMEで入力を確定した瞬間に二重にデータが来てしまう。abcと入れるとデータはabcabcとなってしまうのだ。詳しく追跡すると、

* ControlがWM_IME_CHARを受け取ると、
* その文字に伴うKeyPressイベントを発生させた上で、
* さらにWM_CHARを自身にPostMessageする

　ということがわかった。なので、PostされたWM_CHARがさらにKeyPressイベントを発生させて入力が二重になるというわけだ。つーかマイクロソフトよ、この動作じゃダメなことは一回でも動作実験すりゃわかるだろ？　漢字文化圏の人のことは何も考慮してませんかそうですか。

　.NET1.1のときはこんなことはなかったので、.NET2.0の動作でそうなっているのは確かだ。しかも入力確定時の場合だけで、部分確定のときにはWM_CHARは発生しない。

　なので、WM_IME_CHARをWndProcに渡さず自前で処理するようにして何とかうまくいくようになった。でもこんなやり方では、例えば.NET3.0になったらやっぱり動作しなくなるだろうしな...

　僕もうかつな仕様変更をして苦しむことはもちろんあるので偉そうなことは言えないが、こういう変更を気軽に行う体質が例えばWindows Vistaのリリースの遅れになってるんだろうな、と思う。