General information
Category:
Forms & Form designer
>>>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
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only