Use the install ontimer script step. I think it was there in 11 as well.
Attach it to a load of the layout for example.
You could just make the script run every n minutes or use a script trigger that resets the timer everytime you hit a key.
The script itself would just do a commit records for example.
1 of 1 people found this helpful
"I was hoping that it would be that simple. Thanks for the heads up -DJ"
Yes, you can do this (as suggested by rrrichie). However, there are certain caveats associated with doing so.
I have systems where users do not like even the automatic commits associated with, say, clicking out of a field. They cite use cases where they accidentally overwrite data in a field and then commit it without meaning to. It's quite disconcerting to lose data because you didn't mean to save a change. Hence, in those cases, I've implemented a purposeful "save" feature based on turning off the "automatically save" checkbox in Layout Options.
Another rather annoying glitch with performing an automated commit is losing focus while you're attempting to enter data. That's very disruptive. You'll need to account for what happens if a user is actively typing in a field when your trigger fires (i.e., you don't want to kick them out of what they're doing in the middle of entering data).
Be certain your users and the business rules can tolerate automatic commits before implementing.
If you use our MBS Plugin, you can query the idle time of the user:
or run a script if user is idle a given amount of time:
Yeah funny how FileMaker states the timed script wil run on idle time, but it's a different idle than that we think off :-).
I use the trigger event : onLayoutKeystroke to reset the timer each time. But this doens't reset the idle timer if one clicks in a field. On the iPad the GestureTap trigger can also be used.
I agree with Mike that it's nicer to just have a save button. For really important fields I have an automatic log built in so you can always see the previous values. (Based on UltraLog by Nightwing).
Really good discussion here.
The "conflict" between expected behaviors:
- Never saving before the user choose save (like in old time Word Processing, Spreadsheets, DtP etc).
- Automatic transparent saving without roll back (FileMaker standard) when the record for some reason, that the user may not understand, is committed.
- Automatic transparent saving with roll back (Pages, Numbers, Keynote and other modern Mac Apps) where saves is done all the time, and you only have to save if you want a "save as" or a duplicate.
For FileMaker the transparent method without roll back have worked fine as standard for many many years. And we have the opportunity to turn of automatic commit and add a save button or dialog where the business rules tell us to. The old way may come under pressure with WebDirect and when using FileMaker Pro on unstable WAN connections. Interesting new situations.
Good Stuff Guys,
Confirms my thinking that Filemaker Developers are some of the most comprehensive and creative thinkers in the world. Thanks for all the advise. -DJ
FoxBase used to save each field/record when you tabbed out of the field. Never lost much after a crash. Microsoft bought it and wrecked it. Joined the modern db guys and started using a form of global rather than the field itself. Foreced the user to click a save button. Same can be implemented in FileMaker by using globals and scripts but most developers are too lazy for that, right?
I placed object names on the most crucial fields required for input.
My on timer script runs and grabs the object name and cursor position, commits the record and returns the user to where they where, it happens fast enough not be be disruptive. Not sure exactly how it affects performance, but I'd rather have my data safe, so it's the best solution I could come up with (without major work)
I understand the issue. But one question: Do you have very large text fields where people enter and edit text?
In our solutions we never in real life had this problem. People tend to use the database to enter data end get data and results and perform actions ... in most cases they do not use them as you would use a spreadsheet, PowerPoint or a text editor: They leave the field and everything is safe:-)
Yes I think the problem arises when a user tabs to another field, gets a phone call or goes for coffee. At that moment the record isn't committed yet.
What I have done is on "important" fields have a trigger that saves/logs the value and previous values and commits the record the minute a user exits a field.
I also have layouts with an "interface" so the interface fetches the underlying record, users modify and writes it back. The drawback there, is a lot more changes can dissapear if something goes wrong. So I restrict this to only some parts of the solution (like collecting a new contact/job entry (from external sources), it's checked by the user and then submitted to the database. If anything goes wrong he/she can simply re-collect the new contact from the external source and resubmit)
Actually data-loss is very rare in FileMaker solutions. Mostly it's that another user is in the record you want to manipulate or if a script updates things in the background. You just need to program for the record locks others may have on "your" data-set and update those later.
On one iPad solution, I created my own keyboard and use the same trick, but since the user never really enters a field (otherwise the iOS keyboard shows up) I can't request the cursor position and would just append the next character. But reading your post, just gave me an idea to track my own cursor position. Thanx :-)
Yes you really do have to be creative! I programmed some apps for ZenDesk and it's actually too easy (once you get how it works)
The FileMaker quirks force you be creative and although I have been doing this for so long, I still learn new "tricks". Mostly because new versions of FileMaker expands the toolset you have at your disposal.
I think I speak for most of us here, that we have created things we didn't think where possible in the past and through collaborating here we have been able to turn some beasts (and slow) solutions into slicker, faster versions!