仮想リストビューコントロールの（メイン）バッファにいくつの行を入れるべきですか？仮想リストビューコントロールの（メイン）バッファにいくつの行を入れる必要がありますか？
私は純粋な 'c'でWin32 APIにアプリケーションを載せています。アイテム（実際には行）を取得するデータベースへのODBC接続があります。
MSDNのサンプルコードでは、エンドキャッシュの固定サイズバッファーが30であることが示されています（これはほぼ確実に最適ではありません）。私は、エンドキャッシュとメインキャッシュは同じサイズでなければならないと思います。
バッファーは、リストビューで一度に表示できるアイテムの最大数を超える必要があります。 Listivewのサイズを変更するたびにこれを再計算することができると思いますか？
または、固定値が大きい方が良いでしょうか。もしそうなら、その価値は何ですか？
ビューの矩形の高さを取得するには、ListView_ApproximateViewRect（またはLVM_APPROXIMATEVIEWRECTメッセージ）を使用します。
アイテムの高さを取得するには、ListView_GetItemRect（またはLVM_GETITEMRECTメッセージ）を使用します。
ビューの高さをアイテムの高さで除算して、ビューに収まるアイテムの数を取得します。 各サイズイベントに対してこの計算を行います。
それに応じてバッファを作成します。
LVN_ODCACHEHINT通知メッセージは、いくつのアイテムを尋ねるかを知らせます。これは、キャッシュの大きさを決める際に役立ちます。
@Brian R. Bondyアイテムの数を取得する方法を明示的に助けてくれてありがとう。 ListView_GetCountPerPageを使って（リストビューやレポートビューのために）それを行うことができるということを理解する準備が整いました。ListView_ApproximateViewRectを必要としませんがListViewの新しいサイズを知ることができます。
@Lars Truijens私はすでにLVN_ODCACHEHINTを使用していますが、バッファサイズを設定するために使用していましたが、SQLデータの最後まで読み込んで、返される行数を取得する最後の項目を見つける必要がありますODBC。それは、私がLVN_ODCACHEHINを呼び出す前に、アイテムの数を設定しなければならないと思うので、バッファを埋める必要があると思います。
私の本当の疑問は、ブライアンが答えに示唆した最適化の1つだと思います。バッファを破棄してメモリを再割り当てする際のオーバヘッドの量は、ネットワークに出てODBCの読み込みを行うオーバーヘッドよりも小さく、バッファをかなり小さくして頻繁に変更するものもあります。
これは正しいですか？
LVN_ODCACHEHINTは、通常、メインバッファを正しく埋め込み、レポートモードの行が部分的に見える場合にのみミスすると考えられます。
キャッシュのサイズの答えは、表示されたアイテムの合計数と表示されたアイテムの1行です（アイコンビューでは1行に複数のアイテムがあるためです）。
次に、WM_SIZEおよびLVN_ODCACHEHINTのそれぞれが異なる開始および終了項目番号を持つ場合は、キャッシュを再読み込みします。バッファのための一般的な答えとして
を（またはNotesのランダムなコレクションは、私がアイデアを周りいじるとして）：
答えがあるように見えるでしょうフルこの場合には、いくつかの量で画面を起動し （I次の部分が部分的に覆われている場合は余分な行を追加します）、画面がスクロールされるたびにバッファサイズを2倍にします（メモリが足りなくなるまで）。
これは間違っているようです。わかるように、データをロードするほとんどの方法は、すべて準備完了です。ファイルI/OのODBC呼び出し。私が考えることができないほどのものは、記憶にあるか、その場で再計算されます。これは答えが本当にであることを意味します：LVN_ODCACHEHINTで提供されている値を取ってください（どちらか一方を追加してください - これは積分高さがない場合にはより速く動作するようです）。