>In my particular case, I don't have to worry about deleted rows because my gr id >always points to a cursor which results from a query, so there are no delete d >records. But I'd feel better if I knew a simple sure-fire way to know how ma ny >rows are in the grid. In that case, Recc() will work for you - grid shows complete cursor, no filter, no deleted records. >y appear as needed. To know if the vertical scroll is needed, I need to know h >ow many rows are in the grid (and the number of visible rows). It's really r at >her annoying that the control doesn't have this capability automatically. Guess what - EditBox has this capability automatically. Just create a five-line or more of an editbox, run the form and start typing. Once you fill half the second or third line from the bottom, a scrollbar appears out of the blue. Really, grid seems to be half-finished, and shipped while still green. Bananas and potatos may ripen during transport, but grid is obviously some other breed of an animal. I've tried calculating, the number of visible rows, and was unpleasantly surprised: the RowHeight uses pixels, though the form uses foxels. Really, there's no way to size the controls within an optiongroup, grid (and maybe some others I haven't come across yet) in foxels, which is kind of a nuisance - I'm using foxels just in order to avoid resizing and different resolutions problems, and then I discover that foxels simply don't apply everywhere. Anyway, my calculation proved to be somewhat wrong, I'll yet have to check out why. It's probably because of my trying to measure out a grid on a form which is not shown yet (I set form.height=form.grid.height after I calculate). Just to avoid confusion: I really have two problems, one of them being how to determine the height of the grid - it should be long enough to fit all records available (if they are few) with up to 2-3 empty lines below, but limited with the height of the desktop or topwindow form. The other problem is to know how many rows will really be shown.