1 2 3 Previous Next 38 Replies Latest reply on Jul 24, 2013 2:24 PM by Mike_Mitchell

    Evaluation order


      Does FileMaker evaluate a calculation field before any auto-enter fields ?

        • 1. Re: Evaluation order

          FileMaker evaluates conditions based on a dependency tree. A calculation will reevaluate whenever any of its triggering conditions changes (with some conditions attached). Under most circumstances, this can mean that a calculation will evaluate once prior to the auto-enter value being entered, and then reevaluating once the auto-enter has been updated.


          Perhaps if you give us a more specific example, we could give you a more precise answer.



          • 2. Re: Evaluation order

            Mike_Mitchell ha scritto:


            Perhaps if you give us a more specific example, we could give you a more precise answer.



            Hi Mike


            I think that the attached file is better than 1000 words

            Can you explain me why the calculation field evaluates before the auto-enter text field ?


            Edit: Of course, the calculated field behaves normally when set as not stored.

            • 3. Re: Evaluation order

              Interesting. Let me puzzle on that a bit.

              • 4. Re: Evaluation order

                Hi Daniele, I enjoy seeing lateral thinking ...

                Daniele Raybaudi wrote:


                Can you explain me why the calculation field evaluates before the auto-enter text field ?


                I don't believe it does.  Auto-enters must evaluate first; validations depend upon it ** SEE ADDED BELOW **.  But auto-enter REPLACE behavior is same as calculations; both only re-evaluate when a FIELD from that record *changes.


                Your calculation has no fields.  Without fields it will not re-evaluate (when your auto-enter replace re-evaluates) unless you uncheck 'Do not evaluate if all referenced fields are empty.'


                * auto-enter will fire whenever a field value changes even if it is replaced with the same value as was there prior.  That is why setting a field to itself is sometimes used to trigger auto-enter replace and calcs.


                ADDED:  Auto-enter and validations take place before commit.  Once the record is committed, further re-evaluation must be triggered by field-value change or script.

                1 of 1 people found this helpful
                • 5. Re: Evaluation order

                  Hi LaRetta


                  your explanation is correct when you say that my calculation has no fields.

                  But it will instead re-evaluate when Log re-evaluates, I can even see it while gets a new value... only it gets the prior value of the Log field, doesn't it ?

                  Anyway this is an interesting behavior that could have its own use.


                  P.S.: how do you see my checkbox on Window?

                  • 6. Re: Evaluation order

                    "P.S.: how do you see that chechbox on Window?"


                    I'm unsure of your question, Daniele.  Did you try unchecking 'Do not Evaluate...' in the calculation box and see how the calculation then re-evaluates as you think it should?  It then can re-evaluate and keep up with the Log field.

                    • 7. Re: Evaluation order

                      No, I was speaking about the field "Check" in the posted example.

                      • 8. Re: Evaluation order

                        How do I see that checkbox on Window?  You mean on Windows?  I am currently on my  MacBook Pro.  It produces the  check as you wished, using Webdings check.  I suspect that on Windows box, it might need more room in the field (Windows fields require more space than Mac).


                        So do you understand that your calc was not re-evaluating because of the checkbox in the calc?  It is behaving as I would suspect ... the calc evaluates after the auto-enter (you can see this in action if you create a new record and before you commit it).  At commit, both fields clear because of your use of a local variable. 

                        • 9. Re: Evaluation order

                          LaRetta ha scritto:



                          At commit, both fields clear because of your use of a local variable. 



                          at commit only Log clears, while the calculation field keeps the Log content.

                          • 10. Re: Evaluation order

                            INTERESTING!! To be sure we are talking same thing ...


                            After you uncheck 'do not evaluate' ... if you create a new record both fields fill in, right?  Then when you click onto the layout to commit the record, both clear.  This is standard behavior.


                            If you leave that checkbox (improperly) checked (in the calc), Log fills in but calc does NOT confirming auto-enter takes place first and calc did not re-evaluate.  Then the commit clears the log and fills in the calc which it must do at commit.  If Windows displays different behavior we might have an OS difference here.

                            • 11. Re: Evaluation order

                              No, I can confirm it works the same on Windows or Mac.


                              However, if you change the calculation to unstored, it functions as Daniele wants it to - the calculation reflects the value in the Log field. This causes me to think the storing of the calculation evaluates prior to the dependency updating on the local variables (because local variables aren't in the dependency tree).


                              Just a guess.





                              • 12. Re: Evaluation order

                                And it behaves as Daniele wants also if you uncheck that checkbox DO NOT EVALUATE in the calc dialog.  Not sure why that is being ignored.

                                • 13. Re: Evaluation order

                                  Hazarding a guess (and it's just a guess), I'd say it probably has to do with the local variable. They're not in the dependency tree, so when they update, they're ignored.


                                  Might need someone more versed in the "under the hood" behavior of calculation dependencies to say for certain.



                                  1 of 1 people found this helpful
                                  • 14. Re: Evaluation order

                                    Mike said, "I'd say it probably has to do with the local variable"


                                    Then why does it work when you uncheck 'do not evaluate' even WITH that local variable?   It works because it is behaving as FM should behave ... there are no FIELDS referenced to force the calc to re-evaluate. 

                                    1 2 3 Previous Next