10 Replies Latest reply on Mar 30, 2010 1:34 PM by mrvodka

    Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.

    BroadwayJoe

      Title

      Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.

      Post

      Is there some way to stop or trap Filemaker’s automatic attempt to save records when you move off them (by clicking somewhere else or changing layouts, for example)? 

       

      Here’s the situation:

       

      When the uses opens a particular layout, a trigger script sets up a new entry. One of the fields is auto-entered (a date value). Four of the fields in the record are validated.

       

      On the layout are buttons that Save the record (a script that commits and then ) and another that aborts the current record (does a Revert with no dialog and a New Record). That works fine.

       

      The problem happens because the user at any time can go to a Home layout and can open another window into the same table, but with a different layout (which shows a log of today’s entries). I want to let the user do that without getting any interrupting dialogs if he or she has not made any changes to the record. But I cannot because:

       

      Those actions (leaving the record entry) cause FM to try to save the record. If I set “Save record changes automatically” then FM validates the fields, finds them blank (which is violates the validation) and displays alerts. If I do not set “Save record changes” then FM asks the user if he or she wants to. FM thinks it has a new record with one field entered (the auto-entered date).

       

      I’ve tried to trap (trigger) on Commit, but the Save logic comes before the Commit. What I want to do is to trap the Save. 

       

      I’ve been spending way too much time on this. How do people deal with this issue. Urgent help is needed.


        • 1. Re: Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.
          philmodjunk

          Hmmm, you might be able to use Commit Record[Skip data entry validation] in your script so that you can leave the layout without triggering any validations.

          • 2. Re: Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.
            BroadwayJoe

            Thanks for the suggestion. I have tried that. There are two problems:

             

            1. The main problem is that I don't want to commit when the user, for example, clicks off-record, or presses the Home button, or the button that shows the log window.

             

            Someone suggested that I set up a boolean to indicate whether FM should commit or not, and trap OnCommit. And leave auto-save on. That works well for the click off-record, because I just set up a Return[false] to do nothing (and not commit = no save). But it is a problem when, for example, I want to open the log window. That's because I change layouts (in a different window) in the script that opens the log, which generates a Commit. If the boolean is set False (as it would be because I don't want a Commit in this case, the the "open log window" script aborts half-way through.

             

            2. Commit Record[Skip data entry validation] when auto-save is OFF is triggered after the "Save changes to this record" alert and dialog, so that is not helpful.

            • 3. Re: Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.
              philmodjunk

              What problem (besides the validation rules triggering) are you attempting to avoid by not having the record committed? (There might be a work-around).

              • 4. Re: Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.
                BroadwayJoe

                Maybe so. The way it works now is that 

                 

                1. User goes to layout (by clicking button on home page.

                2. New record is opened with today's date in one of the fields.

                3. User presses button to show log. At that point FM tries to commit, generating message.

                  3b. But the record is mostly empty and does not need to be recorded (having no data other than the auto-entered date).

                 

                If I could open the log window or jump to home (when the record has only the date entry) without committing or saving, that would do the trick.

                 

                So it would be:

                 

                1. User goes to layout.

                2. New record opened.

                3. If user presses "Show Log", log opens without message. If user presses "Home", goes to Home layout without message.

                4. If user clicks off-record, nothing happens at all.

                 

                • 5. Re: Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.
                  mrvodka

                   


                  Broadway Joe wrote:

                   

                  The problem happens because the user at any time can go to a Home layout and can open another window into the same table, but with a different layout (which shows a log of today’s entries). I want to let the user do that without getting any interrupting dialogs if he or she has not made any changes to the record. But I cannot because:


                  You are going to have a hard time with this as when a user goes to another layout, the record will attempt to be committed.

                   

                   

                   

                   


                  Broadway Joe wrote:

                  I’ve tried to trap (trigger) on Commit, but the Save logic comes before the Commit. What I want to do is to trap the Save. 



                   

                   

                  Not sure what you mean here but the commit is the save. You could have it result in a Exit Script [ 0 ] if you do not want it to commit. However, I dont think this is going to solve your issues.

                   

                  The other option is to store your values into global fields and then write a script to save to the real table only when you are ready much like a web form.

                   

                   



                  • 6. Re: Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.
                    philmodjunk

                    What should happen to this new record if the user leaves all the other fields empty and just clicks "Home"?

                     

                    One option that takes some scripting and additional design work is to define matching global fields for all your data-entry fields and place these on your layout. Then capture all your input in these fields--using a script that creates a new record and then uses a series of set field instructions to transfer the data from the global fields into the new record. This then puts off all validation until you are through opening windows and entering data into all the fields. (You may have to change your validation rules to "validate always" or include validation tests in your script with this approach.)

                    • 7. Re: Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.
                      BroadwayJoe

                      Mr_vodka suggests the same (globals). I'll give it a try.

                       

                      What I really want to have happen with the new record is nothing. That is, leave what is in the fields until, for example, the log window is opened and displayed. But I understand that FM doesn't do that.

                       

                      What I don't want to do is bug the user about saving when he actually hasn't entered anything (just FM has put in an auto-entered date).

                       

                      If I could trap the event, then I could even force a commit if anything besides the date was filled in, or at least give the user the option to save or not.

                       

                      Tim

                       

                      P.S. If I use globals as you both suggest, is there a way through calculation or scripts to validate a field according to the same criteria set up in the field definition? That is, is there a "validate this field" calculation or script? Can I tell FM to validate a single field against the database field options (such as "4 digit dates" or "entry date" or "one of a list"?

                       

                       

                      • 8. Re: Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.
                        philmodjunk

                        I haven't tried this, but I suspect you might be able to change your validation settings from "only during data-entry" to "always" and then use Get (LastError) to trap for validation errors after each Set Field step.

                         

                        There isn't any function that I know of for validating a field using its validation rules.

                        It is possible to construct expressions that will produce the same results as each such validation setting--though some take more work than others.

                        • 9. Re: Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.
                          BroadwayJoe

                          Thank you for all your help. I'm going to mark this as solved now and come back if I still can't make something work. 

                          • 10. Re: Intercept or trap and trigger on Save and Validate. Can I and how? Getting desperate.
                            mrvodka

                             


                            Broadway Joe wrote:

                            P.S. If I use globals as you both suggest, is there a way through calculation or scripts to validate a field according to the same criteria set up in the field definition? That is, is there a "validate this field" calculation or script? Can I tell FM to validate a single field against the database field options (such as "4 digit dates" or "entry date" or "one of a list"?

                             

                             


                             

                            Yes. You could use the same validation techniques as you would with regular fields.