1

いくつかのネストされた に基づく中程度の複雑さのレイアウトがありますTableLayoutPanel。フォームのサイズを変更すると、より深くネストされたテーブル内のコントロールが、サイズ変更に遅れて表示されます。まず、これにより、フォームのサイズ変更中にコントロールが動き回るように見えますが、さらに悪いことに、コントロールが割り当てられたテーブル セルを離れるのに十分遅れると、コントロールの端が目に見えてクリップされます。

これを防ぐ方法はありますか、それともこれが最善のTableLayoutPanel方法ですか?

編集: たくさんのプログラムを試してみた結果、サイズ変更の遅れはどこにでもある問題であるという結論に達しました。私には、これは避けられないことであり、許容できることであると誰もが辞任したようです。もちろん、それが実際に避けられない場合、これを受け入れることははるかに簡単です:)

お気に入りの「優れた UI」プログラムのラグを確認する最も簡単な方法: 左の境界線を保持してサイズを変更し、すべての右揃えのコントロールが飛び回るのを確認します (または、ステータスバーのように、上端と下端に配置されたコントロール)。あちこち壊れています。

ネイティブの Windows コントロールを使用するときにこれが避けられない理由を誰かが提供できれば、その答えを受け入れます。また、これに悩まされないネイティブ コントロールを使用するプログラムを見つけた場合は、そう言ってください。

4

3 に答える 3

2

Windows のネイティブ コントロールの問題は、各コントロールがそれ自体を描画する責任があることです。これは、ビットマップを画面に描画することを意味します。コンテナー コントロール内の各コントロールのサイズが変更されると、それが占めるウィンドウの領域が無効になるため、コンテナー内の各コントロールが再描画されるだけでなく、コンテナー自体も再描画する必要があります。また、サイズ変更/再描画イベントはすべて UI スレッドで発生するため、シングル スレッド操作です。ネイティブ ウィンドウ描画の背後にある基本的なメカニズムは、16 ビット ウィンドウが導入されてから変更されていません。

ダブルバッファリング、オフスクリーンレンダリング、単にサイズ変更を無効にするなど、問題を回避するために人々が採用する多くのトリック (ハック) があります。

それがどうあるべきかを確認するには、WPF を見てください。MS は、この問題を解決する手段としてこれを開発しました。

WPF がオプションではなく、Windows フォームを使用している場合は、Microsoftのレイアウト関連のドキュメントを参照してください。すぐに使用できる Microsoft 製品に依存するのではなく、独自のレイアウト エンジンを実装できます。

于 2009-08-27T05:43:35.233 に答える
1

これは、WPF を含め、まったく可能ではないようです (実際にはさらに悪い -この質問を参照してください)。Qt は、Aero が有効になっている場合を除き、このような遅延を回避できます。はぁ...

于 2009-10-03T17:38:58.283 に答える