1つのキーを押すために、処理できる複数のイベントがあります。
あります：KeyDown、、KeyPressed。KeyUp
アプリケーションがこれらのイベントをこの順序で受信することが保証されていますか？
つまり、一連の異なるキーが押されたのではなく、単一のキーを押したイベントの順序です。
コンテクスト：
従来のC++アプリケーションでkeypress-eventsに問題が発生した後、。を使用してイベントを検査しましたspy++。そこで私は、順序が正しくないように見えることがあり、すべてのまたはkeypressedに対して解雇されないことを確認しました。keydownkeyup
しかし、イベントは正確にその順序で発生するはずだと確信していましたが、インターネット上で何も見つかりませんでした。だから私はここでこの質問を思いついた。
これは多言語の問題ではないことに注意してください。ただし、これがC ++、Java、およびC＃に当てはまるかどうかに関心があります。
ほとんどのアプリでは、発生時にこの順序で発生する必要があります。ただし、ウィンドウには、入力されたすべての文字のすべてのイベントが表示されるとは限りません。
たとえば、Windowsでは、キーを押したままにすると、キーが繰り返されるときに、KeyDownおよび/またはKeyPressed繰り返し表示され、キーが離されると1つ表示KeyUpされます。
しかし、今考えてみると、Windowsはウィンドウへの投稿WM_KEYDOWNとWM_KEYUPメッセージのみを開始します（フォーカスがある場合のみ）。 WM_CHARメッセージ（Win32の類似物KeyPressed）は、メッセージループがを呼び出したときのメッセージに基づいて投稿されますTranslateMessage。これは2つのことを意味します：
WM_KEYUPであり、スタックではありません）が、キューにそのキーのキーがすでに存在する場合（たとえば、ユーザーがヒットしてリリースした場合）別のメッセージが処理されている間にキー）、対応するものWM_CHARがその後に表示される場合があります。WM_CHARに呼び出すかTranslateMessage、自分で翻訳を行う必要があります（そのようなメッセージを投稿する別のアプリを除く）。後者の場合、メッセージが投稿される順序はわかりません。また、コメントで述べたように、キーが押されているときにフォーカスが切り替わると、KeyUpまたはが表示される場合がありますKeyDown。（キーの状態はフォーカススイッチの前にすでにそのようになっていて、Windowsはおそらくそれについて教えてくれません。）そしてデッドキー（それ自体でキャラクターを生成しないもの）はまったくトリガーしませんKeyPressed（ただしそれらは通常トリガーKeyUpしますKeyDown）。彼らは通常、次の実際のキャラクターを待ってそれを変更するだけです。
そのすべての短いバージョンKeyDown：イベントが相互に関連して表示される順序に依存できます。、、KeyPressedさらにはKeyUp。ただし、少なくともWindowsでは、3つのメッセージタイプは実際には相互に調整されていません。したがって、すべてが（またはその逆）にKeyUp一致するとは限りません。または、の前に表示されます。KeyDownKeyPressedKeyUp
おそらく、文字とキーのどちらを処理するかを決定する必要があります。それはここでの混乱の一部だと思います。この2つは実際には異なる概念であり、ほとんどの場合、実際にはどちらか一方しか気にしません。Win32は、イベントを処理するときにキーコードを通知すると言われていますが、KeyPressedそのイベントの本当の目的は、入力された文字を通知することです。（それが呼ばれWM_CHAR、ではない理由がありWM_KEYPRESSます。:)そして、なぜ.netのKeyPressEventArgsタイプにはaだけがあり、 .netはKeyCharありませんKeyCode。）他の2つは、キーボードを基本的にボタンの束として扱います。
Windowsユーザーの場合、ここでの経験則は次のとおりです。ロギングまたはデバッガーでイベントの順序を確認し、これが常にそうなると想定します。
これは完璧ではありませんが、95％のケースで機能します。Windowsチームは、これが何かを壊すと100％確信しているので、何かを変更するために常にプッシュバックするという話を何度も耳にしました。
これは、Windows2.0時代の不十分なドキュメントの直接の結果です。