2

クライアントが Windows メッセージの処理を続行する必要があるゲームに取り組んでいます。そうしないと、ゲームが悪用される可能性があります。ウィンドウのサイズ変更とドラッグ イベント中のこの問題を解決するためにWM_TIMER、メイン イベント ループを再開する 50 ミリ秒ごとに発生するメッセージがあります。

問題は、ユーザーがウィンドウ化されたクライアントの X ボタンまたは最小化ボタンをクリックしたままにしておくと、この手法が機能しないことです。(そのため、クリックは完了せず、クライアントを停止するだけです。)

Spy++ を使用すると、最後に表示されるメッセージは次のとおりです。

<00731> 00160D3C P WM_NCLBUTTONDOWN nHittest:HTCLOSE xPos:1150 yPos:178
<00732> 00160D3C P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:1014 yPos:-23

その後、マウスを動かすまで何もWM_TIMER表示されず、マウス ボタンを離すまでメッセージは表示されません。

問題は、マウスをウィンドウの X ボタンの上に置いた状態で、クライアントを再び動かすためにキーオフできるものはありますか? WM_TIMERまたは、「ウォッチドッグ」メッセージが発火するようにできることはありますか?

4

3 に答える 3

4

システムメニュー（あなたの場合のように）やウィンドウのサイズ変更などの一部のシステムイベントは、通常のウィンドウメッセージの処理をしばらく停止します。アーキテクチャを再考し、セカンダリ スレッドで定期的な操作を実行する必要があります。そこでは、メッセージベースのタイマーの代わりに WaitForSingleObject または単に Sleep() を使用できます。

于 2011-11-08T16:37:14.960 に答える
3

いくつかの可能性が考えられます。

  1. 非クライアント領域でボタンが押されると、ボタンが離されるまで、システム コードが独自のメッセージ ループを実行している可能性があります。このメッセージ ループは、WM_TIMER メッセージをディスパッチしない可能性があります。

  2. WM_TIMER は優先度の低いメッセージであるという点で特別だと思います。WM_TIMER は、取得するものが他にない場合にのみキューから取得されます (WM_PAINT に似ています)。Windows タイマーは最終的に起動し、指定された時間よりも早く起動することはありませんが、定期的なハートビートが必要な場合はあまり信頼できません。

別の人が示唆したように、物事を存続させるために 2 番目のスレッドに頼る必要があるかもしれません。

于 2011-11-08T16:52:42.287 に答える
0

定期的な待機可能タイマーの使用を検討してください。別のスレッドで独立して実行されます。

于 2011-11-08T16:54:31.990 に答える