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.
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.
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.
"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?
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.
"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.