There is not really anything for this without an interruption. You could do an OnObjectEnter script trigger that installs a timer script to commit a record and return the cursor to it's position, but you run the risk of dropped characters if the timer runs while a user is typing quickly in the field.
The other common approach would be to have data entry completely on the users device, and then sync records and changes at a separate time completely. A lot of people are using this with FMGo, so that they only use the concurrent license during the data transfer, and not for the entire user session.
One of the issues with what you're trying to do, is that when you have a record open, it's locked to that user, and subject to the user's actions to commit the changes. So you can't use PSoS to have the saving done server-side since the record is locked.
On long data entry forms in the past, I've just added a "save" button to the layout in addition to the native filemaker actions that commit a records. I don't recall any complaints regarding lost entries, but I'm not sure I've had clients that have been writing long text either.
Although one thing you could try (subject to character limits on script parameters) is to use PSoS to send the current text of the field to the server and have it saved in a series of successive records tied to that user's account name (and perhaps device and table and key field and whatever else). Once the user does commit, then you can erase those temporary records. If you had to roll back, you could pull the latest saved record from the temporary table that corresponded to the various keys.
Just a thought exercise, completely untested.
I have users that need to enter a lot of text in a field which can be problematic if they get disconnected from the network. I create a script that traps for the field name, commits the record and then returns the cursor back to the field. This script can be triggered with a key combination (i.e.; Ctrl + 1). This allows the user to not remove their fingers from the keyboard. The same script can be used for any field on the layout.
What methods do people use to automatically save changes to a text field in the background, without interrupting the user?
Is there a common approach for this?
I don't think so. Also because it's quite hard to estimate the importance of the field's contents for the user. But I can imagine that you could have a $$ text array of 100, increase it with 1 mod 100 and store the field contents into array[$i] every 3 seconds or on every keypress or every fieldModify. Being done in globals and in memory the user would not sense any latency. With 2 arrow buttons you can navigate through the 100 repetitions back and forward.
I've really dropped this one down while watching TV after a 10-hour work day, it's plenty of improvements and errors that yell and whine to be fixed, but it shows better what I meant. Use it with the Data Viewer window open (Fm advanced needed).
Circularbuffer.fmp12.zip 65.7 K
Interesting, thanks. I'll take a look.
I suspected something like the PSoS approach or this would be involved… or some kind of dynamic local option.
I just want to boost my users' confidence in editing things at any length in a FM app.