Easy FileMaker modal edit dialogs with full rollback support
Artie Brosuis of Soliant Computing re-visits the transactional technique for rolling back changes to a record when the need arises. Brosius spends a lot of time explaining why and when this is necessary, and even more time showing the proper implementation. This is good. The more detail, the better, especially for beginners and intermediate level developers:
Let’s say you have a requirement to prevent users from accidentally editing field values in the main layout of the application. As we all know, the default behavior of Browse mode is to allow direct editing of field values, including fields of related records in portals. So, to achieve this requirement, you will need to make these fields and/or portals read-only on the main layout and provide an alternative method for editing these fields. Let’s then say that the requirement further states that the user should be able to cancel whatever changes they have made while editing and all changes should be “rolled back”.
A common approach to these requirements is to provide an “Edit” button on the main layout that opens a modal popup window displaying the fields to be edited along with “Cancel” and “Save” buttons. You might then use one of two techniques to collect the data and provide rollback. One, you might use global fields to collect the data and then script the process of copying the data into the real fields when the user clicks “Save”. By using global fields, when the user clicks “Cancel” the script only needs to close the window to leave the original data untouched. Alternatively you might copy the real data into script variables when the window opens and allow the user to edit the actual fields on the layout. If the user clicks “Save”, their edits are simply committed, but if they press “Cancel” the script copies the original data out of the variables and re-populates the fields with the data that was present when the window opened. This is a common technique, and it works fine for simple situations…
Fortunately, there’s a much easier way, and it takes advantage of FileMaker’s built-in support for transactions. Much has been said about transactional processing in FileMaker, most prominently by Todd Geist. I’ve used transactional techniques in a number of systems where the script requires “all or nothing” processing. In the technique I’m about to describe, we are going to use a script trigger to “capture” and prevent the database commit operation that FileMaker natively and silently performs for the user as they work in Browse mode. Only when the user clicks “Save” will we allow all the data to be committed to the database.
One cautionary note: this technique depends upon the record not being “Committed” until the user specifies. Be sure to clear any script triggers from any field that might “Commit” a record for some reason, or you’ll find your rollback not rolling back. Read the rest, and browse the comments for more info.
via Easy FileMaker modal edit dialogs with full rollback support.