基本的に、問題は Windows でのウィンドウのサイズ変更中の境界のちらつきに関するものです。
私の最初の目標は、ダイアログのサイズ変更中にダイアログのコントロールを再配置することでした。
この操作ではほとんどちらつきがなく、適切な動的再配置ができたと思いますが、ここではメイン ウィンドウの境界線のちらつきについて説明します。
しかし、私はそれを完全に取り除くことができませんでした。
例を単純化するために、提供されているデフォルト コード VS を使用して単純な win32 アプリを作成してみてください。
デフォルトのテーマ（Windows 7の基本、透過性なし）とVS2008を使用して、Windows 7（64ビット）でテストしています。
1) アプリにコードを追加しないでください。
2) デバッグモードで実行します。
3) ウィンドウの左端をゆっくりと画面の左側にドラッグし、同時にウィンドウの右端の境界線に注目します。再描画が実際に行われているのがわかります。
4) 手順 3 を繰り返して、マウスをすばやく動かします。右端のちらつきがよりはっきりと見えるはずです。
エッジを反転すると、つまりウィンドウの右端が移動し、左端はペイントされていない領域なしでしっかりとそこにとどまります。上端の境界線と下端の境界線でも同じプロセスが発生します。
ここで、クラシック テーマ (Win2000 に似たもの) を有効にして、上記の手順をもう一度繰り返します。右端はちらつきもなくバッチリ！デバッグ モードで実行しているときに Visual Studio の [出力] ウィンドウを監視すると、exe と共に読み込まれた dll のリストが表示されます。デフォルトのテーマを使用してデバッグ モードで実行すると、uxtheme.dll がロードされていることがわかります。逆に、クラシック テーマを有効にすると、uxtheme.dll は読み込まれません (dwmapi.dll は常に読み込まれます)。おそらく uxtheme.dll はデスクトップ設定に基づいて実行時にロードされ、ウィンドウの非クライアント領域を再描画するために動作します。
このちらつきの効果を確認するために使用できるもう 1 つのトリックは、WM_NCPAINT のケースを追加し、DefWindowProc() を呼び出す代わりに 0 を返すことです。上記の手順を繰り返してすばやく移動すると、ウィンドウの右端の大部分が背景ウィンドウによって完全に消去されていることがわかります。これは、上と下のものには起こりません。
このちらつきを解決するアイデアはありますか?
ありがとうございました！
UPDATE 2012\09\04:
- Windows クラシック テーマの場合:
uxtheme.dll は起動時に読み込まれますが、dwmapi.dll は読み込まれません。ただし、Uxtheme.dll は、
どのウィンドウ レンダリング プロセスにも関与していないようです。ウィンドウのリサイズは完璧です。
- Windows 7 テーマ (境界線の透明度) を使用する場合:
起動時に uxtheme.dll と dwmapi.dll が読み込まれます。Uxtheme.dll
は、ウィンドウの上部とメイン メニューの一部を除いて、非クライアント領域のどの部分にも関与していないようです。
でもラストはよくわからない。ウィンドウのリサイズは完璧です。
-Window 7 Basic テーマの場合:
起動時に uxtheme.dll と dwmapi.dll が読み込まれます。Uxtheme.dll は
、非クライアント領域のレンダリングで頻繁に使用されます。ウィンドウのリサイズが悪い。