最近のトラックバック

2021年7月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
無料ブログはココログ

« 兵隊やくざ | トップページ | セリエAが面白くなってきた件について »

2006.05.10

.NET2.0のWM_IME_CHAR処理

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

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

 まず、上記の騒動は、
* UserControlではImeModeプロパティの設定を無視してIMEを強制オフにしてしまう。これを回避する方法はない。
* しかも、それは.NET2.0のβ2から正式の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のリリースの遅れになってるんだろうな、と思う。

« 兵隊やくざ | トップページ | セリエAが面白くなってきた件について »

コメント

どうもご無沙汰しています。
あまりコメントできませんが、時折のぞくのを楽しみにしています。

MSは何も考えていないわけではないんでしょうけど、
いろいろ過去のしがらみを抱えて大変なんでしょうね。
↓に書かれているように過去の遺物が存在するのは
「メジャーOSの宿命」としてやむなしと思いますが
ライブラリのお仕事を自分のところの都合で
放棄するのはいかがなものかと思いますよ。

http://home.catv.ne.jp/pp/ginoue/im/win32.html

MS製品なんだからver3になるまでは
いろいろ期待する方が無理なのでは?

コメントを書く

(ウェブ上には掲載しません)

トラックバック


この記事へのトラックバック一覧です: .NET2.0のWM_IME_CHAR処理:

« 兵隊やくざ | トップページ | セリエAが面白くなってきた件について »