Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Bug in GetnextModified
Message
From
02/09/2012 04:21:03
Walter Meester
HoogkarspelNetherlands
 
 
To
01/09/2012 04:24:30
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
01551928
Message ID:
01552229
Views:
72
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 wonder why the VFP team did not implement it this way?

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")
>
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform