またながーーい投稿になってしまいました。
DoEventsに関してはこれで言いたいことは全部です。
2度押しが起こる理由は、メッセージがキューに入るからです。
キューをなくすことはできませんが、
マウスイベント・キーボードイベントのみキューに入らないようにすれば
2度押しは起こりません。
これはフックなどで実現できます。
昔、やってみたことがあります。
ものすごく不快でした。
遅いコンピューターを使っていると、
イベントがキューに入ること前提で作業するようになってしまいます。
それを禁止されたので、
作業が終わったか、ジーっと画面を眺めなくてはならず、
目も心も大変疲れました。
一律に2度押し禁止は、不快に思う場合もありますので
2度押されたらまずいもの、処理に少し時間がかかるとわかってるもののみ、
個別に対応するのがよいと思います。
私の方法は2度押し防止ではなく、イベント処理中は無効化するという方法なので、
あるイベントを処理をしている間、特定のボタンを無効化したい時などはかなり楽です。
各Clickイベントの先頭にIfを一個、代入を一個置けばいいだけです。
前の投稿で書いたように、処理の最後でもダメな場合もあります。
モーダルダイアログもClickなどの「決まりきったイベント」で使わなければ危険です。
この「決まりきったイベント」が何であるか、資料はあまりありません。
～のイベントの時は安全である、といったような資料は今のMSDNではみつかりませんでした。
(昔はあったような…。)
私はClickとIdle、Timer.Tickでしか使いません。
ClickとIdle、TickならOSが変わってもComCtl32が変わっても、安全に使えると考えていて、
(これにはいくつか理由がありますが、割愛します。)
Win16時代から使っていますが、不具合はありません。
DoEventsに何か期待しているようですが、
DoEventsは普通にメッセージループを回すだけです。
知る限り、特別なことは何もしません。インテリジェンスはありません。
これ以上の複雑さを避けるためにも、互換性のためにも、そうあるべきだと思います。
#そして、静かに消えていって欲しいと思ってます。
DoEventsを呼んだ場合、きちんと動作するよう組むのは当然プログラマの責任です。
ですが、DoEventsを呼んだ後は、ControlやApplicationがどんな状態になっているのか、
現実的には知りようがありません。
その状態でもきちんと動作するよう、
DoEvents呼び出し元・他のイベントがきちんとコーディングされているのでしたら、
DoEventsを使おうとなんら問題ありません。
これは現実には難しく、
大丈夫であることが保証できるコード、保証されてるコードを私は知りません。
テストを厳密に行うと、合格できるコードは殆どありません。
イベントドリブンの価値は操作・作業の分割にあります。
ある作業中にその作業に関連したイベントが次々呼ばれるのは正しいのですが、
関係のない他の作業に手を出す=メッセージループを回すのはそもそもおかしいのです。
DoEventsはたくさんのイベントを呼び出す、ある意味分岐に相当するわけですから、
網羅率100%のホワイトボックステストを要求されたとき、
DoEventsは一個でもあるなら、テストは現実的には不可能です。
#もともとはそういう困難を解決するためのイベントドリブンなのです。
私が知っている私視点のDoEventsの歴史的経緯を書いておきます。
調べたわけではないですし、当時はまだお子様だったので、
曲解してる可能性がありますが、何かの参考にしてください。
DoEventsやモーダルダイアログ、イベントドリブンの問題は
Windows3.0/3.1の頃に大きな話題になっていたと記憶しています。
おそらく日本では、そのころからWindowsのイベントドリブンプログラミングが
普及してきたのだと思います。
当時たくさん書籍もでましたし、NiftyやPC-VANの掲示板、ニュースグループなどでも
如何にプログラミングするかで盛り上がっていたと思います。
いままでの逐次実行型の概念が抜けず、
生産性が落ちて苦労している人がたくさんいました。
とくに既存のコードをどうやったら簡単に移植できるか、それが重要でした。
DOSの時代は画面を自分で書いて、メニューも自分で書いて、
処理を開始したら終わるまで処理し続ける、という感じなプログラムで、
中に自前のメッセージループのようなものが(複数)あるのが普通でしたから、
移植の際にはそのメッセージループをGetMessage、DispatchMessageに変更し、
自分で行っていたボタンや文字列表示をコントロールに置き換えるのが
一般的な方法でした。
これと同じことをVBでやるときに、DoEventsがありました。
本当の所は知りませんがあちこちで、それをやるためのメソッドである、
という論調で言われてましたし、私もそうだと思ってました。
昔のVBのヘルプには、似たようなことが書かれていたと思います。
私が指摘したようなDoEventsの問題は当時からあったので、
Windowsのプログラムを最初から組むなら、DoEventsは使うべきでなく、
きちんとイベントドリブンなプログラムを組めと言われていました。
まぁそんな感じで、
DoEvents=「過去の遺産を生かすための一時的メソッド」と認識していたので、
.Net1.0を使い始めて、未だにApplication.DoEventsがあるのを知った時は驚きました。
ネット上にもあちこちにDoEventsを多用したコードがあります。
何か画期的方法で問題点が解決したのかと調べましたが、
いまだに当時と同じ問題がありますし、
それに加え.Net固有のイベントもありますから、さらに複雑な状況になっています。
今のプログラマは初めからWindowsのイベントドリブンなので、
DoEventsを知らなくても十分プログラミングできそうなのですが、
2度押し防止のためのキュークリアや、処理時間がかかる時のストレス緩和のために、
DoEventsを使うという、応急処置的方法で使うことが多いようです。
DoEventsを使わないで済まそうと思うと、
イベントハンドラをDoEventsの所で二つに分け、状態を何処かに保存しなくてはいけません。
その手間を考えると、DoEventsは便利なのでしょう。
ネットに転がってるコードはサンプル程度がほとんどですから、
あまり問題は起こってないようですが、
DoEventsやモーダルダイアログの問題をきちんと認識して使ってる例は見当たりません。
というか、問題を正しく認識すると、対処がかなり難しいのもわかるので、
本当に簡単な場合しか使えないはずです。
昔からの経験、いやな思い出などのせいで、私の中ではDoEvents=ダメと直結してます。
ほんとはフィードバックに、「DoEventsは削除して欲しい」と投稿したいくらいですが、
便利だと言う人がたくさんいると思いますし、
「私は使わないし、使われると困るし、見てると不快」
という理由では削除してくれないと思いますから、我慢してます。
違う意見をお持ちの方は是非聞かせてください。
私の説明で納得できた方は
使ってる人にやめたほうがいいと勧めていただければと思います。
そのうちObsoleteになってくれるかな、と期待してます。
#問題が発生したといわれても、DoEventsを使ったコードなんてとてもデバッグできないのですよ。
#そんなコードは捨てて、きちんと作り直すべきなのですよ。
以下、関係ない雑談です。
本来はそうあるべきなのですが、人間の思考力・時間は有限です。
思考がめんどくさい時はブランドに頼るのが常です。
ここは匿名でなく、しかも発言者の同一性が保証されてますから、
今日現在☆4つでMVPのtrapemiyaさんの発言は「☆4つでMVP」として
認識されると思いますよ。
私は流し読みをするときは、有益な情報の多いであろう☆の多い人、
名前をよく見かける人の話から読みます。
つまり、☆は勲章であると同時に他者への大きさを表す、責任でもあるわけです。
Slashdotも似てますが、貢献度というのはうまい仕組みですよね。
無料で投稿させているのに、貢献度を表示させることで責任を課すこともできるのです。
だから全ての人によく見えるよう、投稿者名の所についてるんでしょうね。
投稿した人に感謝を示すだけなら、プロファイルだけに表示すればいいはずで。
いわゆる社会的地位より厄介ですね。リターンが殆どないですから…。
VB2005 ボタン二度押し防止方法
