1 2 Previous Next 21 Replies Latest reply on Nov 14, 2014 12:56 AM by CICT

    Lack of OnRecordExit layout trigger


      I'd be intrigued to know whether anyone else has also been restricted by the lack of a complementary trigger to OnRecordLoad?


      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). Our options include:


      OnRecordCommit - this does not run if the record is already committed when the user leaves the record and we would want to allow the user to commit during their editing without firing the script


      We can trap for:

      Finding another record - OnModeExit

      Leaving the layout - OnLayoutExit

      Navigating to another record via the book icon in the task bar - Custom menus for Go to Next/Prevous records


      However, this still leaves an exposure if the record slider is used, a number is entered directly in the record number or show omitted is used in the status toolbar.


      We could create a global variable by hijacking the New Record command and refer to this using an OnRecordLoad trigger in the record subsequently navigated to, record this new record number, script a return to the original record, perform our scripted procedures and then return to the subequent record, but again this doesn't account for the use of show omitted records where the found set would be different. We could also use Open New Window, search for the old record, run the script and close window, but as most of our solutions run on Windows this can lead to screen refresh issues and there is always the small chance another user has taken ownership of the previous record and we get a record in use error.


      It seems strange that we've mostly had triggers in pairs - OnLayoutEntry/Exit, OnModyEnter/Exit, but OnRecordLoad is on its own.


      It is possible we may get new triggers in future versions and this one has been requested within the new features web page, but if anyone has found an elegant alternative to the above, we'd be interested to hear from them.



        • 1. Re: Lack of OnRecordExit layout trigger

          Andy -


          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.



          • 2. Re: Lack of OnRecordExit layout trigger

            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

            OnRecordCommit, no?



            • 3. Re: Lack of OnRecordExit layout trigger

              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



              • 4. Re: Lack of OnRecordExit layout trigger

                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.

                • 5. Re: Lack of OnRecordExit layout trigger

                  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




                  • 6. Re: Lack of OnRecordExit layout trigger

                    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!

                    • 7. Re: Lack of OnRecordExit layout trigger

                      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.

                      • 8. Re: Lack of OnRecordExit layout trigger

                        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 .

                        • 9. Re: Lack of OnRecordExit layout trigger

                          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.

                          • 10. Re: Lack of OnRecordExit layout trigger

                            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



                            • 11. Re: Lack of OnRecordExit layout trigger

                              Hi Malcolm.


                              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!



                              • 12. Re: Lack of OnRecordExit layout trigger

                                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.



                                • 13. Re: Lack of OnRecordExit layout trigger

                                  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. 

                                  • 14. Re: Lack of OnRecordExit layout trigger

                                    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.



                                    1 2 Previous Next