UpdateLayeredWindow()アプリには、視覚的な表現を処理するために使用するレイヤード ウィンドウがいくつかあります。レイヤード ウィンドウに関する MSDN の記事によると、「アプリケーションを使用しているときは、他の描画メッセージUpdateLayeredWindow()に応答する必要はありません。」WM_PAINTそれらは非レイヤード ウィンドウと同じメッセージ ハンドラーの一部を共有していたのでWM_PAINT、ターゲットがレイヤード ウィンドウの場合は処理から早く戻ることにしました。
もちろん、これは 1 つの大きな問題を引き起こしました: 階層化されたウィンドウの 1 つがメッセージを受け取った場合、入力キューは終わりのないメッセージWM_PAINTストリームであふれてしまいWM_PAINTます。ウィンドウは検証されず、ペイントする必要があると考え続けるため (検証やBeginPaint()ing などを行わずにハンドラーから戻るべきではありません)、この最終結果は理にかなっていますが、意味をなさないものは何ですか?を使用していたウィンドウには影響しないため、そもそもメッセージを受け取ったのはこのためUpdateLayeredWindow()です。
ウィンドウのピクセルの再描画が必要になるたびにではなく、時々発生するだけで、確実に発生するわけではありません。DefWindowProc()階層化されたウィンドウがメッセージを受け取ったときに戻って正気を取り戻しましたWM_PAINTが、理解できない何かが起こっているように感じます. そして、この問題がめったに現れなかったことを考えると、これがさらに微妙な問題を隠しているのではないかと心配しています. UpdateLayeredWindow()時折WM_PAINTメッセージを取得するために使用しているウィンドウに期待される動作ですか? 私がそれを正しく扱う限り、それは問題ですか？
必要に応じて追加情報: ウィンドウはUpdateLayeredWindow()作成直後に呼び出され、その後はそのまま残されます (変更されないため、再度呼び出されることはありません)。C++ と win32 API を使用し、MFC は使用しません。