>From HELP:
>GETNEXTMODIFIED( ) returns 0 if there are no modified records after the record you specify. Because of this, if you
>modify only one record, to verify its modification you must first use the GO TOP command to position the cursor
>before the changed record. A record is considered modified if the contents of any of its fields are changed in any way
>(even if the original field contents are restored) or the record's deletion status is changed.

Which is incorrect in several points. When not using the lNoFire parameter, you don't have to use GO TOP. It just works.
Its description is in conflict with the first parameter which indicates from which record it searching for modified records. help says:

"Specifies the record number after which GETNEXTMODIFIED( ) searches for the next modified record. Specify 0 for nRecordNumber to determine the first record in the table or cursor that has been modified."

and it works exactly that way if lNofire is set to false. If lfire is set to .T. it
1. does not recognise the changes in the current record
2. except when a GETNEXTMODIFIED() function has been executed earlier with lNoFire set to .F.

There is another line in help:
"lNoFire prevents the flushing of temporary data, such as data stored in controls or updates made to the current record, to the underlying cursor."

Which does not make sens to me. In my application the GETNEXTMODIFIED() function is executed on a timer to determine the change status of a cursor and enable a undo button if changed. The getnextmodified() function does not flush the data of a control to the underlying cursor or else this would cause problems in my application. For example an incomplete date in a control cannot be flushed to the underlying cursor as the field would not accept the value and would as a result blank out the field and cause my control to go blank while I'm typing the value. This is not happening, so I wonder what they really mean with the statement above. Perhaps its about fields that have a field check or a primairy index (the stuff that lNofire ignores), but this description certainly needs more clarification.

I would consider this a bug in either the implementation or design. Also at the very least the documentation in the helpfile is highly confusing; if not, just plain wrong.

Walter,