ダイアログマネージャーが自身を閉じる方法のカスタマイズ：ESCキーの検出、2回目（失敗）の試み

前回、GetAsyncKeyState関数について見ました。 この関数は、イベント発生時にESCキーが押されていたかどうかを教えてくれるという点では役立ちますが、ESCキーが押されていたからといって、そのメッセージを受け取った理由がESCキーであるとは限りません。 例えば、あなたの方針が単にESCキーを無視し、ユーザーが閉じるボタンをクリックした場合にのみダイアログを閉じるものだとします。ユーザーがESCキーを押し続けながら閉じるボタンをクリックした場合、ESCキーの最初の押下がIDCANCEL通知を生成します。 そして、次のIDCANCEL通知は、閉じるボタンによって生成されます。 ただし、これはESCキーから来たものではありません。閉じるボタンから来たのです。たまたまESCキーが押されていただけで、二つ目のIDCANCEL通知を受け取った理由はそれではないのです。 二つの入口、裏口と正面入口がある部屋にキオスクを設置していると想像してください。誰かが正面ドアから入ってきたら受付係を呼び出したいのですが、裏口から入ってきた場合はそうしたくありません。ESCキーをチェックすることで私たちがやっていることは、「もし裏口が開いていたら、受付係を呼び出さない」と言っているようなものです。しかし、誰かがちょうど裏口の戸口に立ち、ドアを開けたままにしている間に、別の誰かが正面ドアから入ってくる可能性があります。あなたのロジックは裏口が開いていることを検知し、一度に開いているドアは一つだけだと想定していたため、受付係への呼び出しを抑制してしまいます。 次回は、ESCキーと閉じるボタンの区別について見ていきます。

ダイアログマネージャーが自身を閉じる方法のカスタマイズ：ESCキーの検出、2回目（失敗）の試み

背景や根拠まで確認しますか？

調べる

選ぶ

サイト