仮想リストビューコントロールの（メイン）バッファーにはいくつの行が必要ですか？
Win32APIに対して純粋な「c」のアプリケーションを作成しています。アイテム（実際には行）を取得するデータベースへのODBC接続があります。
MSDNのサンプルコードは、エンドキャッシュ用に30の固定サイズのバッファーを意味します（これはほぼ確実に最適ではありません）。エンドキャッシュとメインキャッシュは同じサイズにする必要があると思います。
私の考えでは、バッファは、リストビューで一度に表示できるアイテムの最大数よりも多くする必要があります。Listivewのサイズが変更されるたびに、これを再計算できると思いますか？
または、大きな固定値を使用する方がよいでしょうか。もしそうなら、その値は何ですか？
ListView_ApproximateViewRect (または LVM_APPROXIMATEVIEWRECT メッセージ) を使用して、ビューの四角形の高さを取得します。
項目の高さを取得するには、ListView_GetItemRect (または LVM_GETITEMRECT メッセージ) を使用します。
ビュー rect の高さをアイテムの高さで割り、ビューに収まるアイテムの数を取得します。各サイズ イベントでこの計算を行います。
次に、それに応じてバッファを作成します。
LVN_ODCACHEHINT通知メッセージは、要求するアイテムの数を知らせます。これは、キャッシュの大きさを決定するのに役立ちます。
答えは次のように思われます:(または私がアイデアをいじくり回しているときのメモのランダムなコレクション）
バッファの一般的な答えとして：ある程度の量から始めます。この場合は画面がいっぱいになり（次の行が部分的に覆われていない場合に備えて行を追加します）、画面をスクロールするたびにバッファサイズを2倍にします（最大でメモリが不足する前にポイントします）。
これは間違っているようです。結局のところ、データをロードするほとんどの方法は、すべてすぐにバッファリングされます。ファイルI/OのODBC呼び出し。私が考えることができないほとんどすべてのものは、メモリ内にあるか、その場で再計算されます。つまり、答えは実際には次のとおりです。LVN_ODCACHEHINTで提供される値を取得します（そして、いずれかの側に1を追加します。これは、整数の高さがない場合に、より速く機能するようです）。
@BrianR.Bondyアイテムの数を取得する方法について明示的なヘルプをありがとう。実際、私はListView_GetCountPerPageで（リストまたはレポートビューに対して）実行できることを理解する準備ができていて、他の人のためにそれを取得する方法を使用しますが、私はListView_ExplicitViewRectを必要としないのですべての準備ができて、ListViewの新しいサイズを知ることができます。
@Lars Truijens私はすでにLVN_ODCACHEHINTを使用しており、それを使用してバッファーサイズを設定することを検討していましたが、SQLデータの最後まで読み取って、ODBCから返される行数を取得する最後の項目を見つける必要があります。'end cache'を埋めるのに最適な時期なので、LVN_ODCACHEHINを呼び出す前に、アイテムの数を設定する（したがって、バッファーを埋める）必要があると思います。
私の本当の質問は、ブライアンが答えをほのめかした最適化の1つだと思います。バッファを破棄してメモリを再割り当てする際のオーバーヘッドの量は、ネットワークに接続してODBC読み取りを行う場合のオーバーヘッドよりも少なく、バッファをかなり小さくして頻繁に変更するものもあります。
これは正しいですか？
もう少し遊んでみましたが、LVN_ODCACHEHINTは通常、メインバッファーを正しく埋め、行（レポートモード）が部分的に表示されている場合にのみ失敗すると思われます。
したがって、キャッシュのサイズの答えは次のとおりです。表示されたアイテムの総数に加えて、表示されたアイテムの1行（アイコンビューでは行ごとに複数のアイテムがあるため）。
次に、開始項目番号と終了項目番号が異なる場合は、WM_SIZEとLVN_ODCACHEHINTごとにキャッシュを再読み取りします。