5

に何百もの「アイテム」を表示するダッシュボードアプリケーションを作成していFlowLayoutPanelます。

各「アイテム」は、UserControl12個のテキストボックスまたはラベルで構成されています。

私のアプリはデータベースにクエリを実行し、各レコードの「アイテム」インスタンスを作成し、ラベルとテキストボックスにデータを入力してからに追加しFlowLayoutPanelます。

パネルに約560個のアイテムを追加した後、タスクマネージャーの数が約7300に増えたことに気付きUSER Objectsました。これは、私のマシン上の他のどのアプリよりもはるかに多いものです。

560 * 13（12個のラベルとUserControl自体）は7280であると考えました。そのため、すべてのオブジェクトがどこから来ているのかが突然わかりました...

Windowsがタオルを投げる前に10,000USERオブジェクトの制限があることを知って、私はこれらの「アイテム」をに描画するより良い方法を見つけようとしていFlowLayoutPanelます。

これまでの私の考えは次のとおりです。

  1. 多くのラベルの代わりに、を使用graphics.DrawTextして「アイテム」をユーザーが描画します。これが13ではなくDrawImage1アイテム=1を意味することを願っています。USER Object

  2. 「アイテム」のインスタンスを1つ作成し、レコードごとにインスタンスにデータを入力し、Control.DrawToBitmap()メソッドを使用して画像を取得してから、FlowLayoutPanel（または同様の）で使用します。

だから...誰か他に何か提案はありますか？

PSこれはズーム可能なインターフェイスなので、すべてのアイテムを一度に表示する必要があるため、「ページング」はすでに除外しています。

4

3 に答える 3

2

少なくとも、私はあなたのアイデア #1 から始めます。これにより、実際にアプリケーションが飲み込んでいるウィンドウの数が 13 分の 1 に減少します。

あなたのアイデア＃2に関しては、BitmapをPictureBox（または何でも）に入れて、フォームに多数のPictureBoxコントロールがある場合、それはまったく役に立ちません（ビットマップは時々一般的な RAM よりも限られたリソースで構成されており、これはウィンドウの消費量が多すぎることとはまったく別の問題です)。これは、結果のビットマップを取得し、それらを 1 つの大きなコントロールにコピーする (そしてビットマップを破棄する) 場合にのみ良い考えです。

この後者のアプローチを採用する場合、コントロールへのレンダリング、コントロールのビットマップ コピーの取得、およびそのビットマップの最終的なコントロールへの描画という中間ステップを実際に利用する必要はありません。コントロールをレンダリングするために使用するコード/ロジックを取得し、代わりに最終的な (複数要素の) コントロールに直接レンダリングする方が理にかなっています。

于 2010-06-10T15:57:41.510 に答える
1

私は＃1を実装して良い結果を出しました。

ユーザーオブジェクトが13分の1に減り、応答性も速くなります。

提案をありがとう-これがより一般的な問題ではないことに私は驚いています！

于 2010-06-11T08:38:16.947 に答える
1

あなたのアイデア＃2は私がお勧めするものです。これはまさに、何千ものレコードを表示することを目的としたリストおよびグリッド コントロールがインプレース編集を実行できる方法です。1 つのコントロールから始めて、必要な場所に移動します。

同時に複数のインスタンスを表示する必要がある場合は、少し難しくなります。おっしゃるとおりDrawToBitmap、コントロールの「ゴースト イメージ」を使用して表示する必要があります。

別の方法として、ここで何らかのスクロールが行われていると仮定します (7280 個の UI オブジェクトを一度に実際に見ることはできませんよね?)。そのため、実際に画面に表示されるインスタンスのみを動的に作成することもできます。同時に。表示領域を計算し、それを表示するコントロールのリストと比較する必要があります。UI がズームアウトしすぎて実際に詳細を確認できない場合は、プレースホルダーを表示するだけです。ただし、これを行うと、スクロール/ズームはかなりCPUを集中的に使用する操作になると思います。まったく作成しない方がよいでしょう。

于 2010-06-10T15:29:13.933 に答える