>Hi Fabio,
>
>I came to the same conclusion that the GO TOP() or any other command that changes the record pointer was needed to update the change status of the current record. I have no idea why this poor design was implemented. This strategy cannot be used in my framework as that would flush data in controls to the cursor while a timer executes this command 20 times a second.
>
>There is a simple workarround
>
>

lChanged = GETNEXTMODIFIED(0,"Test",.T.) <> 0 OR (!EOF("Test") AND GETFLDSTATE(-1,"test") <> REPLICATE("1",FCOUNT("test")+1))

>

you can remove !EOF("Test"), it is useless.

>You wonder why the VFP team did not implement it this way?

Because on VFPT's mind GETNEXTMODIFIED(0,"Test",.T.) with .T. parameter
means that the record has not yet changed.

Then your's workarround is not a workarround but the correct VFP code!

I learned to use VFP for what it is,
I do not expect me to do what I want.

>
>Walter,
>
>
>
>>>All,
>>>
>>>In debugging our application we found the following VFP bug.
>>>
>>>According to the help documentation, which seems to be full of errors BTW. When the lNoFire flag is used to prevent field validation to happen the function does not recognize the changes in the current record when the recordnumber is set to 0
>>>
>>>

CREATE CURSOR Test (Dummy int)
>>>APPEND BLANK
>>>
>>>CURSORSETPROP("Buffering",5)
>>>REPLACE Dummy WITH 1
>>>
>>>? GETNEXTMODIFIED(0, "Test", .T.)
>>>? GETNEXTMODIFIED(0, "Test")

>>>
>>>The function with the lnofire set to .T. returns 0, while the second one returns 1.
>>>Also if you reverse the order of both functions, both will return 1
>>>
>>>I'm not sure whether this bug has been reported before, but if not... here it is.
>>
>>Hi Walter,
>>on backstage, VFP puts data on many levels data structures.
>>With tablebuffer, the record data is stored on level 1,
>>when an internal pointer changes the data is written on the table buffer ...
>>This is an optimization for multiple current record updates.
>>Optimization have a cost, the cost is the great errors or side effects probability,
>>and VFPT pay this cost here!
>>
>>It's a bug ?
>>If the VFP designer add lNoFire parameter to search others buffered modified records
>>without touch the current record, then it is not a bug.
>>Wanting to be magnanimous, this is the interpretation which I consider most likely.
>>
>>For the VFP's help,
>>the fact that suggests GO TOP as a method to write data
>>on table buffer shows that the knowledge of the writer are
>>rather vague on how VFP works internament.
>>The help documentation must be written by programmers!!
>>
>>Hi.
>>
>>

>>CLEAR
>>
>>CREATE CURSOR Test (Dummy int)
>>APPEND BLANK
>>
>>CURSORSETPROP("Buffering",5)
>>REPLACE Dummy WITH 1 && this line doesn't change the record status
>>? GETNEXTMODIFIED(0, "Test", .T.) && lNoFire doesn't move the internal VFP record pointer
>>REPLACE Dummy WITH 1 && this line doesn't change the record status
>>? GETNEXTMODIFIED(0, "Test", .T.) && lNoFire doesn't move the internal VFP record pointer
>>REPLACE Dummy WITH 1 && this line doesn't change the record status
>>REPLACE Dummy WITH 1 && this line doesn't change the record status
>>
>>? GETNEXTMODIFIED(0, "Test", .T.)
>>? GETNEXTMODIFIED(0, "Test", .T.)
>>
>>GO RECNO() && this move the internal VFP record pointer
>>
>>* then now GETNEXTMODIFIED return the change
>>? GETNEXTMODIFIED(0, "Test", .T.)
>>
>>* without lNoFire parameter GETNEXTMODIFIED move the internal VFP record pointer
>>? GETNEXTMODIFIED(0, "Test")
>>