One possible way around this is to use some global variables to track the current record and then fire the script OnRecordLoad. If the variables differ (because they're populated, as opposed to empty when you first enter that screen / area) then you could execute your code.
Not perfect, but it is a workaround.
A typical situation is that we want to allow a user time to carry out
editing a new record but once they leave the record we perform a
script (say for setting some tasks in a portal).
OnRecordExit would be triggered prior to leaving the record, not after
leaving the record.
You haven't made a case for OnRecordExit. It is an action that will
perform on every record, whether or not there has been a change to the
record. In your example you'll generate related data. Would you do that
just because a person has looked at a record? If the opening of a record
was important you'd do that OnRecordLoad (log: user x opened record y).
Now, if the user doesn't make any changes to a record, why do you want
to add or change related records prior to exit? If the change you want
to make does not depend on the user entering data then it can be done
OnRecordLoad. If it does depend on the user entering data it can be done
Thanks MIke, so far an approach similar to this is about the only way we've found to do it and unfortunately you do get the Windows window resize/flash even with freeze window set if you want to leave the found set untouched.
Malcolm, we don't need to make a case here. We have a customer who has a busiiness requirement that relates to the creation of invoice schedule records. OnRecordExit would solve this problem immediately in one simple step, but as it doesn't exist we are left with the creation of unwieldy get arounds that take significant development time and the introduction of unecessary complication to our systems.
Thanks for your interest
I would love a OnRecordExit trigger.
I don't like field-level validation because there's a lack of control. I would put a lot of validation-type checks into an OnRecordExit script. A script that checks is there a first name and a last name? OK, proceed. No, are you sure you want to exit? OnCommit doesn't satisfy because users don't understand the "Commit" action like developers do. "So what I clicked out of the field, I wasn't done adding the person's name yet!"
Globals, a button in the background, etc those add complexity where a new trigger would suffice.
I still don't understand why you need OnRecordExit and why
OnRecordCommit isn't useful. I guess that is at the heart of my previous
Malcolm, apologies for not taking time earlier, but will try a quick explanation behind our thinking. OnRecordCommit is incredibly useful, for instance we very rarely use calculation fields these days, especially cross table calculations in a solution using data separation, so for a simple totalling of order line items in an order we may trigger a script either from a field or from OnRecordCommit to set the totals, tax, discount, etc. Alternatively we may use the same technique to enforse validation rules - the data remains as simple as possible in the data file(s) and the business intelligence is built into the user interface file.
However, although a record will always eventually be committed, even by the process of navigating away from the record, there are also times when the record will be committed, redited, committed again, prior to leaving the record. At this point there is no way of triggering an action unless you change mode or layout. As described in my original posting, custom menus can be useful but they cannot be used to trap for every method of navigating within FileMaker.
We have many examples where a final action is required prior to leaving a record and the logical method of doing this would be a complementary trigger to OnRecordEnter, i.e. OnRecordExit. In one of our current projects we have an Orders record that has a jobs/tasks portal that is automatically populated as part of the new record script. These tasks are intelligently linked to each other (a cannot happen before b, etc.) and feed into graphical installations and manufacture/production layouts used by the factory and installation teams. Once the order has been created and the financial element is finalised, the tasks are planned and updated immediately afterwards. The key element of this system is that the invoice scheduling (part payments, staged payments, etc.) is dependent on selected tasks and must not be created until the user has had a chance to finalise these tasks. The workflow dictates that the only safe time to create the invoicing schedule is when the user leaves the record. If the record has already been committed, then we have no elegant way of running the invoice schedule creation. If we could guarantee that someone would revisit the Order prior to an invoice schedule report being run, then we could use OnRecordEntry, but this is not going to happen.
The above is an abridged version of just one example but I hope it explains things a bit clearer.
Just for fun and to show that this is a live scenario, I've attached a photo of a PC in the factory in its dust proof casing, with touch screen that the staff use to prioritise manufacturing and update the upstairs admin staff of progress. The FileMaker production schedule is in the background and if you look closely you can see the order and tasks portal with statuses in the foreground modal window. That mouse won't survive for long in that environment!
Factory PC.jpg 134.4 K
As a developer and as a user, I find the "Commit" action to be non-intuitive. What's so special about clicking outside of a field? In what other non-FM interfaces is that relevant?
Leaving a record, however, that's a natural point for validation.
A user is entering a new contact They are required to enter a first and last name.
They enter the first name, and click outside the field. A scripted error pops up....that's weird. They were planning on putting the last name in, why this dialog?
Instead, they enter a first name, and attempt to naviage away, triggering a dialog...that's way more natural.
My 2 cents
Instead of using the standards tools for moving between records, why don't you create your own 2 buttons for next and previous. You could the do whatever is needed in the attached script.
Unless there is something I missed .
There's lots of ways users navigate away from records...scripting, entering a different mode, omitting a record, closing the database, etc etc. For me, layout triggers act as a central repository for certain logic, so I don't need to place it in all the menus, scripts, etc. Also, I really like using the native FileMaker controls. It makes for a nicer interface and easier development.
I agree that the built in field level validation is a very blunt tool but we are able to design our own tools to fill the gap.
OnRecordCommit fires before the record is committed so you can provide the sort of intelligence you want to run onRecordExit. You can run all of your tests, do what ever you need to do and decide if the commit proceeds or not. Use exit script[false] and the record commit is aborted. Use exit script[true] and the commit proceeds.
In addition, developers have the "commit record" script step which includes the option to commit records without validating. I think you can achieve all that you want from onRecordExit using onRecordCommit.
I've attached an example of controlling onRecordCommit and of Field Validation triggers
FieldValidation.fmp12.zip 68.3 K
You are focussing on a single element raised here.
We have a need that can result in many, many time consuming get arounds AND not all the holes can be plugged by these. Whereas a simple complementary script trigger to OnRecordLoad would resolve these. Based on your arguments so far, why have OnLayoutEntry, OnLayoutExit, why not just do everything from one trigger and create various complicated work arounds?
Many existing triggers are in pairs (or more) - OnEnter, OnModify, OnSave, OnValidate, OnExit. in particular we have OnModeEnter/OnModeExit, OnLayoutEnter/OnLayoutExit so why not OnRecordLoad/OnRecordExit (or OnRecordLeave)?
Please remember that nobody needs a knife until they need to cut something!
I'm simply exploring the problem that you are describing. The example
file shows a method for using onRecordCommit that allows you to
determine the appropriate stage to perform the tasks. As great as it
would be to have OnRecordExit, it doesn't exist, but there seems to be
ways to get what you want, albeit with extra work.
I agree with David and CCIT, it would be nice to have script parameters on those script triggers, we just don't have it now.
But as long as we are asking... why does FM only give us one Script Parameter to pass? Why not have as many parameters to pass as we want? In the programming world, that is ridiculous. I know we play games with passing arrays separated by ¶'s, but its just not elegant.
An interesting update to this as I've just had another example of the need for OnRecordExit where I wish to force the entry into a portal prior to navigating away from a record, which is the corelation wit the OnPanelSwitch script trigger.
First impressions are that we have the opposite problem, as this proceeds before the panel in focus is switched. However, we've 2 functions: Get(TriggerCurrentPanel) and Get(TriggerTargetPanel) that overcomes the problem as to whether you wish to carry out an action before you leave or after you leave.
Yes, I could solve my portal entry validation during Commit, but I don't want to force this entry until the user has had a chance to add other info and constantly interrupt their workflow each time they happen to commit a record. If we can't have an OnRecordExit then if we could have similar functions to the above such as Get(TriggerCurrentRecordNumber) and Get(TriggerPreviousRecordNumber) we could achieve the same goal, albeit with a little more scripting than preferred solution.