Hi, Peter-

Thank you for your detailed and clear explanation.

>Finally, the problem child: PgUp & PgDn. This originally worked well, moved the current displayed records accordingly with DOSCROLL calls. The current recordsource (&highlight) never moved (which was acceptable at first). The problem arose when you hit an arrow or enter... it works off the "current" record, jumps the grid back, and goes from there.
>
>What I want now is a proper scrolling grid with PgUp/PgDn... that is:
>- PgUp:
> - Highlight/Record at 1st row on page... jump one complete page back and
> highlight & recordsource to that first row record
> - Highlight/Record NOT on first row on this page... jump up to first row
> on page and move highlight/recordsource accordingly
>- PgDn:
> - Highlight/Record at last row on page... jump one complete page next and
> highlight & recordsource to that last row record
> - Highlight/Record NOT on last row on this page... jump dn to last row
> on page and move highlight/recordsource accordingly
>
>I am having LOTS of problems getting to that row and displaying it properly. I have tried various mathematics to get the current location using header size, grid size, ActiveRecord, etc, etc. Many needed setfocus calls to the grid temporarily to get the current row info, etc.
>
>Alot of times, the scrolls caused the highlighted row to be the MIDDLE of a grid listing due to SKIP calls etc.. the grid automatically moved it to the middle during the SKIP call.

I haven't implemented exactly the thing you are trying for, and I don't know if this will be helpful, but a couple of thoughts occured to me as I read your post.

- To summarize, it is specifically the PgDn and PgUp behavior that's troublesome, yes?

- Are you comparing ActiveRow and RelativeRow to decide how far back or forward to skip?

- If you are using ActivateCell, then you may not be aware that it will not work unless the entire row is visible in the grid.

- From Hacker's, the RelativeRow is not as smart as RelativeCol. If the relative row is scrolled off the grid, it doesn't become < 0 or > the number of rows, as one would like. It simply becomes 0. So, it becomes difficult to know which direction you need to go.

- Is part of the problem that skipping doesn't seem to *really* take? I just had a grid that used a GO BOTTOM that would be fine til after the lostfocus for the column fired, at which time the record pointer somehow magically went back to the original record. I finally "solved" the problem by putting KEYBOARD commands in the VALID. Weirdly, or maybe not, I had to use the valid and not the lostfocus and it matter how I stuffed the keyboard. I.e. The following didn't work:

KEYBOARD "{DNARROW}"
KEYBOARD "{DNARROW}"
KEYBOARD "{LEFTARROW}"

but the following does work:

KEYBOARD "{DNARROW}"
KEYBOARD "{LEFTARROW}"
KEYBOARD "{DNARROW}"

I have no idea if this will be helpful information, but just kinda goes to show how picky grids are.