I want to run a script whenever a user commits a record in a specific table. Now, I can place a "Save" button on the data entry layout for that table and have that button execute a script that commits the record and performs other steps but the user can commit the record without ever clicking on my button. Is it possible to trap events, like when a user adds a new record or commits the new record?

James McIlwrath

Mississauga, ON, Canada

It sounds like what you are talking about is a ghost file. But I'm not sure from your comments. You are wanting to force the user to push the save button to commit a record over the record just being added automaticaly.:??

There are a couple ways to do it. If the record is added through a portal the key field would only be input if the save button is pushed otherwise the record doesn't show up in the portal but does exist in the file. Moving to a new layout can then delete the un-commited record in the background. That is a little easier then a ghost file.

Well, commiting records is a bit weird. I thought this was a new feature in FM7, but I don't really see much difference in the new version here. Data are committed when you click out of the field or press ENTER or control-enter on a PC. Also, to my way of thinking, the record is not commited, rather, it's commited field by field. Of course, the record (as in all fields) is committed automatically when you select new record, etc... but maybe that is an illusion. But, clicking out of a field (on a Mac) commits the fields you have completed, and there is no way then to revert. I know of no way to trap the event, but if it's possible, I think it would probably require a plug-in.

--Tripod

Your correct the field is committed when you click out of the field and the record is created when you a) add new or : type text in a portal. What I think he was asking was to trap the new record and force the user to save or commit the record to the database. It is possible to do by using a ghost file where the record is entered but not posted to the working file until the user saves/commits. I've only run across this need a couple of times and it is usually when the committed record shouldn't be re-edited.