Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Detect changes in cursors
Message
De
03/02/1999 14:38:06
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00183522
Message ID:
00183578
Vues:
15
>>>Hello all, I need suggestions on detecting changes to my data at the form level. I want to enable Save and Revert buttons and prompt to save/revert when form looses focus. I've seen several complex solutions based on reusability and toolbars, but I just need to manage it at the form level. I always have an application object available, and am using table buffering and private data sessions.
>>>
>>>Any help greatly appriciated.
>>>
>>>Dean
>>
>>dean, If you are using Table buffering (as opposed to record), you will need a combination of GETNEXTMODIFIED and GETFLDSTATE.
>>
>>Changed table fields report that they have been changed to GETFLDSTATE by showing something other than a "1". To check for anychanges, use something like
>>
>>llChanged = GETFLDSTATE(-1) <> REPLICATE("1", FCOUNT() + 1)
>>
>>see the help for GETFLDSTATE for details.
>
>
>Eric, Thanx, I looked at GetFldState before, but was thrown off by Help indicating the return value was numeric. Using str() on it was bugging out (cause it is really returning a string).
>
>But where is the best place to implement this test? I want to enable the save/revert buttons on my form when a change occurred in a row. The user can decide to update now, or continue editing.


I think that the best way to do this is at the framework level. All of the baseclasses for databound controls in my framework know to 'signal' the form in the interactivechange event, to tell the form that a user is making changes. Then the form can decide what buttons to enable, disable.

To make sure that the user dosn't leave the form without saving or reverting changes, you'll need to put the GETFLDSTATE code in the QueryUnload method, or in a method that gets called from QueryUnload. Then have the release method call the run the QueryUnload method.

(Clicking the X button in the corner of the form does not run the release method, and running THISFORM.Release does not call the QueryUnload method, so this is a way to have the same code run no matter how the user attempts to leave the form).

If you want to do this checking before hand, say when the user leaves the page, or when she tries to go to another record, you'll just have to figure out what events happen when this occurs, and do your checking there. Remember, it is best to have a custom method that does the checking, so that you can call this method from several places.
Erik Moore
Clientelligence
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform