「Windows 7はマルチタッチ技術搭載」記事へのコメント

(object sender, MouseEventArgs e[])

[Anonymous Coward]

iPod touchのときも疑問に思ったんですが、
マルチタッチ対応にすると途端にプログラマの負担が
増えるんじゃないかなぁ…と。現状はどうなんでしょう？

Re:

[greentea (17971)]

そりゃ、マルチタッチ機能を使うと手間は増えるでしょう。
CUIからGUIに、シングルスレッドからマルチスレッドに、特殊なデバイスを使用したい……
など、今までなかった機能を使うと手間が増えるのは何ら不思議ではない。

じゃあ、今までのをマルチタッチ機能搭載OSに持っていったらどうなるかを考えてみた。

例えば「はい」と「いいえ」のボタンを同時に押されたらどうなるんだろう？と思ったが、
今でもキーボードとマウスの2入力を持ってて、どっちでもボタン押せるわけだし、
そういうことができると、はじめからきっちり考えて作ってるプログラムは大丈夫かもしれないね。

ただ、キーボードがマウス

--
1を聞いて0を知れ!

Re:(object sender, MouseEventArgs e[])

[Anonymous Coward]

今更ですけど、Windowsでは、「はい」と「いいえ」のボタンを同時に押されても、同時に受け取ることはできません。（普通そうなりますが）両方とも同じスレッドで処理するならどっちかが早いもん勝ちです。

例えば、メッセージボックスであれば、

1. 両方メッセージキューにたまる。
2. GetMessageなどで、どっちかが先に取り出される。
3. はい・いいえどちらであってもウィンドウが閉じられる（この間ExitDialog/DestroyWindowやWM_DESTORYではメッセージキューを経由しない）。
4. 3の結果として、他のメッセージが投げられたら、メッセージキューに貯める。
5. 再びGetMessage。このとき、入力イベントよりも、ポストメッセージが優先されるので4のが先に取り出される。
6. もう片方がキューから取り出されるも、既に該当するウィンドウはないので入力イベントは闇に葬られる。

という具合です。2と5の間にGetMessageが起きないこと、5でGetMessageしたとき、入力イベントよりも先に、2-4の間でPost（など）されたメッセージが先に処理されるというのがミソです。

WindowsでPost/SendMessageされたメッセージが入力イベントよりも優先されるのは、このようにPost/Sendが前に起きた入力を反映して起こっているという見方に基づきます。ですので、はい・いいえでウィンドウが閉じられない場合でも、ゆっくりと、はい押した→いいえ押した（あるいは順番逆）のように順に押したのと同じように処理されます（よっぽどへぼな状態管理を行っていない限り）。まあ、今はプリエンプティブなマルチスレッドなので、複数のスレッドが関わる場合では必ずしもこう綺麗にいくとはかぎりませんけどね。

ちなみに、一般的なPeekMessageの使われ方（VBのDoEventsも同じ）は、一般に2-5の途中でメッセージキューから取り出すということに相当するので、この秩序を乱すことになります。これがPeekMessage/DoEventsは下手に使わないほうがよいと言われる理由です。