UPDATED()

UPDATED() ostensibly tells you whether any of the data in a form has changed since you last saved it. But it doesn’t work right for its purpose.

Usage

lAnythingNew = UPDATED()

Way back in the dark, murky mists of Xbase history, UPDATED() was a useful function. It told you whether any of the items in a READ had been changed, so you could, for example, know whether to prompt the user to save changes when he pressed Escape.

In FoxPro 1.0, a cool new function code was added to @GET. FUNCTION “@M” let you specify a list of valid inputs and force the user to choose from the list. With that function code, UPDATED() began to lose its shine because simply moving through the list of valid inputs set UPDATED() to .T. FoxPro 2 just made things worse—clicking a button, even an OK or Cancel button, set UPDATED() to .T. So did checking or unchecking a check box, or choosing from a list or popup. Most folks wrote their own function to figure out whether a save was needed.

Visual FoxPro’s buffering makes all this a lot easier. With GetNextModified() and GETFLDSTATE(), you can see exactly what’s been changed.

InteractiveChange and ProgrammaticChange let you act as soon as a change occurs, and KeyPress together with KeyPreview lets you figure out what the user is actually doing.

We told people to stay away from UPDATED() in FoxPro 2.x. Lots of things have changed, but this isn’t one of them—stay away from UPDATED().

Example

* This is how you should be able to use UPDATED(), but can't
* This code might go in a Cancel button's Click
* Assume FoxPro.H has been included in the form
* Display the standard 'Save your changes (Y/N)' routine
IF UPDATED()
   nResult = MESSAGEBOX("Save changes", MB_YESNO + ;
                        MB_ICONQUESTION + MB_DEFBUTTON1)
   IF nResult = IDYES
      * call the save routine
   ENDIF
ENDIF

See Also

GetFldState(), GetNextModified(), InteractiveChange, KeyPress, KeyPreview, ProgrammaticChange