You can edit fields on the screen and those changes aren't permanent until you "commit" the record. Filemaker automatically commits data when click on a blank part of the field, change to a different record or switch to a different layout. You can disable automatic updates in layout setup... and this may help. To undo uncommitted changes, you can use the Revert Record/Request command in a script to roll back the recent edits to their last committed values.
Glad to hear from you again Phil! You've helped me before, so I know I'm in good hands.
I tried your advice above. The revert record/request wipes out the whole record. I'm looking to just wipe out one field and reset the calculation so that the grand total it's associated to is what it was before the data was entered. And the Undo was still giving me nothing.
Is there a formula I can put in a script? Maybe one that "adds" itself back before it is cleared??
Thanks again for your help.
You'd have to do some scripting and additional database design to support this. I believe there's also a plug in (called "dataguard?") that may offer help here.
Here's some general "filemaker only" suggestions you can experiment with:
You could use a script trigger to commit the record when the first of the number fields is entered. Then revert will only roll back values for the fields modified after that previous commit takes place.
You could define additional fields that auto-enter copies of the sensitive data (Do not clear the "do not replace existing value.." option). Each time your "commit" button is clicked to commit all the changes, your script would use set field steps to copy the values to the hidden fields. To roll back a value for one or more fields, a script would copy the data the other way.
"I've been able to set-up a script to go to the previous field and then clear the contents of that field, but I also need it to reset the the different totals to what they were before the data was entered."
What has been missed is that your 'calculations' must not be calculations but rather standard number fields with auto-enter set to calculation. If they were true calculations then their values would automatically 'revert' when you removed the incorrect value that was entered. There would be no need to resynchronize anything at all.
In all my years of development, I have never had to reset calculations when data they depended upon changed. If the fields they depend upon is in the same record, they can still be indexed. If any of the fields they depend upon exists in another table occurrence then they will automatically be unstored and will STILL update automatically. If the calculations depend upon many of the Get() functions such as Get ( CurrentDate ) then the calcs should be manually set to 'do not store' in storage options.
Thank you both for your help. I think I'm almost there!
LaRetta, you were right about my grand totals being number fields with calculations in them. I took your advice and changed the field types to calculations, and it does 'revert' the total back to the amount it was before the data was entered. Thank you for that fix!!
There's still one hang up...After changing the field type to calculations, I've lost the option of "value from last record visited", in the auto-enter options menu. Now when I create a new record the grand totals 'revert' back to their originals.
Here's specifically what I'm trying to do. I work for a poker TV show. At our televised final table each player starts with different chip stack amounts. As each player bets, (puts chips into the pot), I want the bet amount to be entered and subtracted from their total chip count, (which is working).
Right now I have it set up so that each hand is an individual record. This is why the "value from last record visited" was important. Before your fix I had it working so that the bet amounts were subtracted from the individual's total chip count as they were entered. I also setup different 'buttons' with calculations attached to them to add the total pot size, (the sum of each player's bets), to an individual's total chip count after winning the hand, (these buttons also have a NewRecord/Request at the end of the script). Once the total pot size is awarded by clicking the individual player's 'Win' button, a new record is loaded and ready for the next hand.
The ONLY hang up was NOT having a way to 'revert' the total chip counts in case of data entry error. With your great advice I've gotten past that.
Now I need the pot totals to "carry-over" to the next record, (or hand), and I'm also getting an error message when I click on one of my 'Win' buttons, (these add the pot total to the players chip total), that says, "this action can not be performed because the field is unmodifiable".
The end goal is to allow us to have "running chip counts" of our final table players without having to stop the game and manually count them.
Thanks again for your help!
We would need to see your file to understand your structure and how best to advise.
I suggest that you upload it somewhere and then provide a link with clear directions on what to look at when we get into the file or, if you are not comfortable with your file being reviewed publicly then private message someone and we can send your our email for sending the file directly.