6 Replies Latest reply on Oct 2, 2014 11:41 AM by dzittin

    Undoing edit changes

    dzittin

      Title

      Undoing edit changes

      Post

      I use an "edit record" layout. When the user is finished editing, I prompt for save, undo or more modifications (continue editing).

      If edit completion is intercepted via  the script trigger "layout exit", the record has been committed by this point. An undo would require that I save each field prior to changes and restore the saved record since a revert does not undo committed records.

      If edit completion is intercepted via the script trigger "on record commit" then all is ok, except if the user clicks outside of a layout data entry panel which commits the record up to that point which means that if an undo is selected only changes made after the "outside" click will be reverted.

      I realize that "outside" clicks are likely to be rare, but not impossible and this could lead to problems. If I use the trigger "on record commit", the user will have the option to go back and make more mods if s/he clicks outside of a data entry panel. Of course, getting the save/undo/continue prompt in the first place from an outside the box click will be confusing to someone entering data.

      Is there a way to prevent  OOTB clicks causing commits, or is the best bet to save the entire record and restore it on an undo and use the trigger "on layout edit" which will not lead to unwanted panel pop ups. 

      Opinions, ideas, facts appreciated.

      Thanks.

        • 1. Re: Undoing edit changes
          philmodjunk

          Option 1: Cover the entire body of your layout with an Empty Web Viewer Object or Button object formatted to be transparent and located behind the fields. (Use appearance setting changes to keep a button from responding to mouse clicks and hover events)

          Either object will keep the mouse clicks on the layout background from committing the record.

          Option 2: Replace all the fields on your layout with a corresponding set of fields that have global storage. Use a script to "save" the data by transferring the data to the original fields. The same script can create a new record or modify an existing record.

          • 2. Re: Undoing edit changes
            dzittin

            Thanks.

            Option #1 seems the best. It's obscure, but from a maintenance standpoint, it's cleaner than trying to keep globals & tables in sync.

            Is this "feature" documented?

            I thought of creating a temporary record in the table and copying into that before allowing edits, but it's a hassle.

            • 3. Re: Undoing edit changes
              philmodjunk

              It's not really documented as a specific item in the help systems, but it exploits the standard behavior of either a button or web viewer layout object.

              Your "temporary record" would not be all that different from Option 2.

              • 4. Re: Undoing edit changes
                dzittin

                "Your "temporary record" would not be all that different from Option 2."

                And probably much more maintainable.

                Is there a way to copy entire records? I have tried copy/paste, but this does not work because the paste tries to paste the entire copied record into the first field of a new record. What am I doing wrong?

                • 5. Re: Undoing edit changes
                  philmodjunk

                  Copy/Paste steps are steps best avoided in good FileMaker design. The steps both silently fail if the referenced field is not present on the current layout and users get irritated with their database solutions when data they've previously copied to the clipboard mysteriously get overwritten while they interact with a FileMaker Database.

                  I don't see that a temp record is more maintainable and that approach can create other issues in situations where a person starts a new record and then cancels out.

                  But to copy a record from one table to another, you can use Import Records after isolating that one record in a found set of just that one record.

                  Some developers will copy the data from one record to another by setting up a relationship and using auto-enter field options on every field to copy over the data. The process is to set a variable to the first record's primary key, then create a new record and set a foreign key field to the value of the variable.

                  • 6. Re: Undoing edit changes
                    dzittin

                    "I don't see that a temp record is more maintainable and that approach can create other issues in situations where a person starts a new record and then cancels out"

                    I guess I was thinking that if fields were added to a record, one would have to remember there is a global save buffer and make the changes there. It's always nice to be able to change data format without having to worry about side effects when possible.

                    Thanks for all your help. I will look into the import auto-enter ideas you proposed.