11 Replies Latest reply on Jul 6, 2012 2:43 PM by xercisepro

    Field Validation and Scripts

    xercisepro

      Every now and again I revisit a piece of code to see if it could be improved on. Unfortunaetly I don't think so this time but thought I'd put it out to the the wider area network.

       

      Pre Condition

      Validation is set within the field dialog with custom dialog supplied.

       

      Background

      As a general practice I include a sub script at the begining of scripts that indirectly cause the comitting of a record and hence catch any field validation repercusions early and proir to any script actions. A validation triggering sub script as such. Please see attached file.

      In effect the validation script commits the record and hence allows the field validation to present errors if applicable.

       

      Problem

      As we know field validation can present different options that require different responses ("Revert Field" "No" "Yes"). So my real problem is does anybody know how to determin while a script is running whether the user chose "Revert Field" as opposed to "Yes". ("Yes" being where the field allows user to override validation). Please see attached file for example.

       

      I have tried using a timestamp field with auto enter of record modification. This unfortunetly updates on "Revert Field" or "Yes".

      Also tried Get( RecordModificationCount" ) which is set to 0 on record creation and remains 0 for either "Revert" or "Yes" on first run. Which seems counter intuitive when you compare to how the timestamp field behaves on creation and then "Yes".

       

      Current working approach

       

      1. Capture errors

      2. Commit the record

      3. If errors are caught then

      turn off capture

      recommit (to see applicable validation message)

      halt script

       

      Although this is nice it isn't elegant because the if the user chooses "yes" to override then there is no reason why the supra script shouldn't be able to continue.

       

      Any thoughts appreciated.

        • 1. Re: Field Validation and Scripts
          BruceHerbach

          Hi,

           

          Took a look at your file.  The record ModificationCount field was failing to update.  I changed it to an Unstored calculation and then it started working.

           

          You can put the value for RecordModifcationCount in the script prior to doing the commit and then test it after to see if the record has reverted.  If Committed,  the modifiaction count should go up by 1, assuming the value actually changed.  If you run the script but haven't made any changes to the value,   then the Modificationcount doesn't change.

           

          So a couple of things to consider.

           

          1) You can attach the script to the field as a script trigger based on either OnModifaction or OnValidate.  If OnValidate you can have the script update a seperate field with a value to determine when/what happened when the script ran.  This assumes you are running Version 10 or 11 with script triggers.

           

          2) You can change the field validate options so that the user can't override the validation.  This will depend on what you or your client wants, but maybe helpful.

           

          3) You can also validate by formula and check the value against other criteria or another field.

          • 2. Re: Field Validation and Scripts
            xercisepro

            Hi Bruce,

             

            Thanks for the response. Yes my demo calc field should have been unstored - I threw that in last minute to illustrate the point clearer.

             

            Your point: " You can put the value for RecordModifcationCount in the script prior to doing the commit and then test it after to see if the record has reverted.  If Committed,  the modifiaction count should go up by 1, assuming the value actually changed.  If you run the script but haven't made any changes to the value,   then the Modificationcount doesn't change."

             

            Can you please confirm this your side because this isn't the result I get. Even with the Get( RecordModificationCount ) field being unstored it still remains 0 whether "Revert" or "Yes" is chosen. (Tested in FM 10 and FM11).

             

            The steps I apply are:

            1. Create new record and type data into field but don’t commit (always start with a new record)

            2. Type “eee” into field

            3. Press Button without comiting record first.

            4. Choose "Revert Field" ---> 0 is supplied as expected.

             

            5. Repeat steps 1-3 ****Make sure you start with a new record*****

            6. Choose "Yes" ----> 0 not 1 is supplied --> the problem

            • 3. Re: Field Validation and Scripts
              BruceHerbach

              Hi,

               

              If you enter a valid value in the field,  then run you script,  the

              modification count will go up.  Run the script a second time without

              changing the value,  the modification count stays the same.

               

              If you enter an invalid value and override the verification,  the

              modification count will go up on the initial commit.

               

              Run the script again,  the field will not trigger the validation formula,

              even though the current value doesn't meet the criteria and the

              modification count doesn't change.

               

              I tried all of this on the version I uploaded earlier.

               

              HTH

              Bruce

               

              Sent from my mobile device... Please excuse typos.

              • 4. Re: Field Validation and Scripts
                BruceHerbach

                After I got back to the computer, I tried this again using the scenario in your last e-mail.  On a new record, over riding the validation on the initial entry or putting in a valid value returns a record modifcation count of 0.  If I modify the value a second time giving another invalid value and over ride the validation or a valid value,  the count does increase on the second invalid value/commit.

                 

                So in short I think this is a case of Computer Science math.  The first modification/commit is 0... So in this case,  0 = 1.   A revert on the

                 

                You can get around this by creating the record,  and then commiting the record before entering a value in the field.  A lot of commercial template systems do this.  When you click the button to create a new record,  they check access, create the record, commit the record and then finally give the user access to the record.  If you do this, your record modifcation count should be the value you expect. 

                 

                HTH

                Bruce

                • 5. Re: Field Validation and Scripts
                  xercisepro

                  Thanks Bruce,

                   

                  I was just creating a video demo as this came through.

                   

                  The inconistent element here is that a reverted record is acknowledged as a modified record from the prespecitve of a timestamp field with auto enter on modification however the Get( RecordModificationCount) does not. My thought is that it should be one way or the other.

                   

                  The problem with the creating and committing a new record is that it disregards empty field validation unless extra logic is included to catch this in every scenario. From a purist perspecive you are overriding your own validation model.

                   

                  My initial point standing, my goal is to maintain working within the validation framework in a very general way (works universally). The hitch is that there seems to be no way to determine the difference between a field being reverted or overriden by the user if allowed.

                  • 6. Re: Field Validation and Scripts
                    user14135

                    Andrew,

                     

                    I started by looking over the FileMaker Pro Error Codes list (validation errors are numbered 500 through 513) and then the Get() function options. It turns out that there's a Get(RecordOpenState) that is probably the best fit for your issue.

                     

                    The return values are:

                    0 (record closed or committed)

                    1 (new record yet to be committed)

                    2 (modified record yet to be committed)

                     

                    So, although I have not tested this yet, it seems as though you could simply check the open state of the record after you turn error capture off and attempt committing the record again to trigger the built-in validation handlers. If the value is zero, the user has approved the data, otherwise they have reverted the record and your script should halt.

                     

                    HTH.

                    • 7. Re: Field Validation and Scripts
                      xercisepro

                      Unfortunately, gave that a go too.The Get(RecordOpenState) for a new record is 1 and returns back to 0 regardless of whether the field is "Reverted" or "Yes" (Overridden). However it is the exact method I used to catch for when "No" was selected. See script in sample.

                      • 8. Re: Field Validation and Scripts
                        Vaughan

                        Andrew Markham wrote:

                         

                        Problem

                        As we know field validation can present different options that require different responses ("Revert Field" "No" "Yes"). So my real problem is does anybody know how to determin while a script is running whether the user chose "Revert Field" as opposed to "Yes". ("Yes" being where the field allows user to override validation). Please see attached file for example.

                         

                        I've always considered the "allow user to override" option to be somewhat superfluous: either I want to validate the fields, or I don't; if I do want to validate then I don't want the user deciding to leave a field empty, for instance.

                         

                        De-select the "allow user to override during data entry" then the user only has the choice of reverting the record to the previous (valid) condition, or changing their data entry so it validates.

                         

                        Actually there IS a test you can do to work out whether the user clicked Yes (to allow the invalid entry): since you are the developer you know the fields being validated, and you know their validation conditions (not empty etc). Compare the current values in the validated fields to the validation calculations. If the validation calculation does not return true for all fields then they have clicked Yes to allow the invalid entry.

                        • 9. Re: Field Validation and Scripts
                          Vaughan

                          You run a nightclub. You have a dress code and a bouncer at the street to enfore the dress code. Every person who passes the bouncer gets a ticket, and every person with a ticket gets let in to the club. The dress code is:

                           

                          no thongs

                          no work clothes

                          no firearms (they can be checked at the door)

                           

                          The bouncers are authorised to sometimes make exceptions and let people in even though they don't meet the dress code. Friends, celebrities, law enforcement.

                           

                          So you know that everybody in the club has a ticket. Everybody should also meet the dress code (no thongs, no work clothes, and no firearms) but some people were let in on exceptions.

                           

                          You now want to work out which people were let in on an exception. These are the people in the club who do not meet the dress code. You need to look at each person and say "if you have thongs or work clothes or firearms then you were let in on an exception".

                          • 10. Re: Field Validation and Scripts
                            BruceHerbach

                            I think this is a case where you can use an OnObjectValidate script trigger to let you know what is going on.  Take a look at the attached file.  It has a simple script that checks the value of the test field and sets another field with the values of Valid or Invalid based on the test.  Even if the record is reverted,  the value remains.

                             

                            Bruce

                            • 11. Re: Field Validation and Scripts
                              xercisepro

                              Feature request submitted