>>>I consider this a serious error since it involves a record pointer movement not specifically instructed by the program or initiated by the user, but for some reason the VFP team did not fix it. I don't know if it fell through the cracks or they just decided it wasn't serious (I would have a hard time fathoming that conclusion!).
>>
>>From the sound of your description I concur. Even if it can be fixed with a few lines of code seems to show some redundant and now behaviour-split code in vfp. OTOH grids are complex beasts ;-)
>>
>>regards
>>
>>thomas
>
>They are complex beasts, I suppose. In fact, some "gurus" say to never do data entry in a grid. I've always thought that was terrible advice. I've done data entry in grids from day one with VFP (I skipped over VFP 3, so for me that means VFP 5 and above) and have had no problems to speak of. Until this bug that was introduced into VFP 8, that is. But that's not even related to a grid doing data entry. It's just serving as a navigation tool.

Hi Russel,

this is a pageFrame bug, the grid it does not have guilt.
It appear with any ActiveControl on a Pageframe's page.

This bug have more serious effect:
The BUG:
If you change the page with ActivePage,
the current ActiveControl don't execute the lostfocus sequence
The effect:
THEN YOU CAN EXIT FROM A TEXTBOX WITHOUT EXECUTE THE VALID CODE;
IF YOU IMPLEMENT A CHECK INTO the TextBox.Valid,
with Activepage = .. VFP DON'T EXECUTE THE CHECK CODE !

With Page.Setfocus,
the Activecontrol execute the lostfocus sequence before to deactivate the current page.

Fabio