Microsoft Access 掲示板

この方法の問題点

dpiによって結果が変わる

ほぼ決め打ちでも問題ないところですが、正確を期すならdpiの取得が必要です。そこまでするとACCESSの埒外になってしまいます・・・

または、実際にレコードを移動させてCurrentSectionTopを取得し、差を吸収するような仕組み（表示上の詳細セクションの高さを求める仕組み）が必要でしょう

>> 15の回避策は大雑把ながら見どころの有る方法だと思います

96dpi(1Pixel=15Twip)の場合のずれは±7で20レコードあれば最大140Twipずれる可能性があるということになります。このとき、詳細セクションの高さが300Twip程度あれば140Twipずれても四捨五入で欲しいレコードの位置を求めることができます

Macのdpiは72だそうです（古い情報ですが）。この場合同様に考えるとずれは最大±10で20レコードだと200Twipずれる可能性があり、高さが300Twipの場合、高さの半分以上の誤差がでるので四捨五入すると1レコード以上の差になってしまいます。しかしながら、この計算でも14レコードまでであれば正確なレコード数になります

限定された範囲では確からしいことが保証できるので

まるめ = Int(先頭レコード + 0.5) '表示が15レコードくらいまでなら大丈夫

のような感じで対応してしまうのも無くはないかなと思います

カレントレコードが変わる

コード以前の問題ですが、CurrentSectionTopの仕様としてカレントレコードが表示エリア内に存在しないとちゃんとした数値が得られません。カレントレコードを変えたくない場合（編集中の場合・レコード移動時イベントを不用意に発生させたくない場合）や、またはカレントレコードを元に戻す手間などが問題になるかもしれません

windows apiを使った手法はこの問題に悩むことがないのもいいですね