リンク > バグ報告 > 8374の双方のやりとり

wxWidgets TracのTicket #8374 Fix for unicode input in wxGrid (partly wxMac-specific)

Macで入力した文字を確定できない問題と同じ問題だと思われる。
勝手に議論を要約させてもらいますが、問題があったら(ry

やりとり(いい加減に要約してあります)
  • 報告者:(wxGridについて)EVT_KEY_DOWNでキーボードのイベントを拾うと、IMに届かなくなる。wxGridCellEditorEvtHandlerはEVT_KEY_DOWNではなくEVT_CHARを使うべきだ。
  • 中の人:私の認識が正しければ、あなたの書いた内容は間違っている。EVT_KEY_DOWNでTab,Returnなどを扱ってもいいだる。実際wxMSWやwxGTKでは動いてるし。wxMacのバグを隠すためにwxGridを修正するのは正しくない。
  • 報告者:(Carbonでのイベント処理について説明)kEventRawKeyDownじゃなくてkEventTextInputUnicodeForKeyEventでEVT_KEY_DOWNを生成するようにすればいいけど、そしたらEVT_KEY_DOWNがフィルタ前のキー押しと対応しなくなる。(Wiki管理人注:いや、生のキーとは対応しないでいいだろ)
  • 報告者:ドキュメントに、EVT_KEY_DOWNは生のキーイベントと対応するってはっきり書いてある。そんで、EVT_CHARが生成される時には文字変換は済んでいる、と。よって、wxMacがキーボードのイベントを処理する方法が正しくて、wxMSWがアプリケーションより前にIMEにEVT_KEY_DOWNを掴ませてるのなら、それが間違ってる。
  • 報告者:さて、問題はなんでwxGridがEVT_KEY_DOWNでキーストロークを処理するかだ。EVT_CHARでいいじゃん。
  • 中の人:wxGridはどうでもいいけど、世の中にはwxGridと同じとこをしているコードが山ほどあるんだ。(注:wxRichTextCtrlとwxStyledTextCtrlとか)絶対にそいつらには動き続けていて欲しい。
  • 報告者:(省略)
  • 中の人:wx-devで議論しようぜ
  • 報告者:WindowsはWM_KEYDOWNが生成される前にIMにキーストロークを傍受させてるみたいだ。(注:TranslateMessageのことか)他にも、Windowsは矢印キーなどについてはWM_CHARを生成しないみたいだ。wxGridの作者がEVT_KEY_DOWNに走ったのもこういうわけか。(wxはそういうキーについてもEVT_CHARを生成するけどね)
  • 報告者:ということはwxチームはWindowsに追従して、ドキュメントに、IMがアクティブでキーを食べてしまったらEVT_KEY_DOWNは動きませんよ、って書くんだろうね。でもその場合、「Windowsがそんなだったから」っていう以外の理由でEVT_KEY_DOWNとEVT_CHARを分けておく意味はあるんだろうか。
  • 報告者:何にせよ、チームがそう決めたのなら、wxMacは先に私が言及した方法で動くようにできる。(注:kEventTextInputUnicodeForKeyEventでEVT_KEY_DOWNを生成する、のことか)OS X 10.5に間に合うのならパッチを書くよ。
  • 中の人:既存のコードを壊さずに、プラットフォーム間の動作を一貫性のあるものにするパッチは歓迎するよ。個人的に、MacのIMがどういう風に動くのか知りたいな。
で、報告から3年経過。

タグ:

+ タグ編集
  • タグ:
最終更新:2010年03月27日 16:58