20 April 2025: Demo and article updated to incorporate a couple tactfully-worded suggestions from Tony White to make the technique more robust. Thank you Tony.
Demo file: transactional-card-window-v3.zip (requires FM 20 or newer)
Resources
- Card windows — Windowing in FM 16: First Impressions
- Transactions — A Practical Guide to Transactions in FileMaker (ClickWorks)
Introduction
Recently a colleague and I were discussing ways one might go about having a card window be both modal and transactional. By default card windows are modal to the “background” window (the window they were generated from), but are not modal to other windows in your solution.
In this case we wanted the card window to be modal to the entire solution, so that once it was displayed the user would not be able to do anything else in FileMaker Pro until they had dealt with that window.
Additionally we wanted to leverage the transactional model, so that edits would take place in standard fields, with changes made by the user committing if they clicked Save, and evaporating if they clicked Cancel. Reminder: transactionality is an all-or-nothing proposition. You either get all your changes or none of them. You never end up with half baked data.
And, finally, we wanted to map the Esc key to the Cancel button, and map the Return and Enter keys to the Save button.
Note: The Return key is often confusingly-labeled “Enter” — Return is the key that generates code 13 and lives above the right-hand Shift key… whereas Enter generates code 10 and is typically situated at the bottom right of your numeric keypad (assuming your keyboard has one).
Overview
We’re going to use a single multipurpose script, “transactional card,” which will branch based on passed parameters.
The basic idea is to open a transaction, and put the user into a paused loop which they can only get out of by either a) clicking Cancel, or b) doing everything they’re supposed to do and then clicking Save. If they click Save without doing everything they’re supposed to do, the loop will iterate and return to the paused state.
The Main Screen
Fields are not editable on this screen. To edit an existing contact, or to create a new one, the user clicks one of these buttons — each of which calls the same script, but with a different parameter.
The Card Window
Here is the card window in layout mode.
There are four things going on here —
- We have a layout calculation in the top navigation part, which makes use of the script parameter.
- Cancel runs “transactional card” with a “cancel” parameter.
- Save performs a single pause/resume step.
- The OnLayoutKeystroke trigger runs “transactional card” with a “keystroke” parameter.
The Script
We begin with an informative preamble, then we load the parameter, and the keystroke (if any), into variables.
Clicking “New Contact” or “Edit” displays the card window, opens a transaction, optionally creates a new record, and puts us in a looping pause.
To elaborate on the comment at step 34: The “Go to Next Field” at step 35 does two things:
- ensures that changes to a given field are recognized by the test at step 36, and
- ensures any auto-enter calculations evaluate… and there are auto-enter calcs scrubbing the data on all the card window fields.
We are are now effectively “trapped” inside a transaction. Clicking Save will unpause the script, and if the test at step 36 evaluates as true then we will exit the loop, the transaction will commit and our changes will be written to the database. If, on the other hand, the test evaluates as false, then we will circle back around the loop and pause once again with any changes uncommitted.
Cancel is straight-forward. No need to explicitly revert — closing the window (i.e., the window where the transaction originated) automatically reverts the transaction, and halting terminates the script chain so we don’t end up stuck in the loop from the original script instance.
30 May 2025: the above comment at line 43 is incorrect. In FM 21, Close Window does not revert a transaction. The following step, Halt Script, causes the open transaction to revert. There has been some confusion around this and it was addressed here: Closing Windows During Transactions.
And finally we selectively process or ignore each keystroke.
If you’re curious about step 54, we are making sure the Return key does not insert a hard return into a field because in this particular instance a) we don’t want hard returns inserted into our fields, and b) we want the Return key to behave identically to the Enter key, i.e., to resume the paused script.