6 Replies Latest reply on Feb 7, 2011 11:29 PM by electric_soul

    BUG?? Local variables not always local.



      BUG?? Local variables not always local.


      I wrote a function 'eval.error' to help me deal with error messages.


      eval.error (

                              "table01::isScrewed    ==>Somebody stepped in crap!";
                              "customer::hasPhone    ==>Mr X has a phone!"


      What happens is, the string to the left of "==>" gets evaluated and if it returns TRUE. Then the message on the right of "==>" will be appended to a variable called $error. Let's say that both values, that are being passed to the eval.error function return a mesage. Then the variable $error would contain 2 values.

      $error = "Somebody stepped in crap!Mr X has a phone!"

      Now......... this function can be used in a script. The more often you use this function, the more might be appended to $error. At the end of the script, the variable $error contains all the errors that occured in a script, and when the scripts exits the variable $error will be deleted, like any other good old local variable.


      When I use the function in a table field, something different happens. I have 2 different fields. Both are calculation fields, and both use the function eval.error. What happens is that they share the variable $error. Now is that suppose to be like that? Is it a bug? This sucks ;)


        • 1. Re: BUG?? Local variables not always local.

          An interesting concept. How are you updating the $Error variable?

          • 2. Re: BUG?? Local variables not always local.

            Well, there is nothing big behind it.

            Here are the two needed functions.

            ApplyToList( ListA ; function ; seperator ){

            Let ([
            V1 = GetValue( ListA; 1);
            expr = Substitute( function; ["[n]"; Quote(V1) ]  );
            Result = Evaluate(  expr  );
            LR = Length( result);
            N = ValueCount( ListA);
            final = result & Case( N > 1; Case(LR; separator) & ApplyToList( RightValues ( ListA; N -1) ; function; separator))


            eval.error( string ){


            function    ="if( evaluate(getvaluecust ( [n]; 1;\"==>\" ));
                                   if(EvaluationError(Evaluate(trim(getvaluecust ( [n]; 2;\"==>\" ))));
                                         trim(getvaluecust ( [n]; 2;\"==>\" ));
                                         Evaluate(trim(getvaluecust ( [n]; 2;\"==>\" )))

            result    =ApplyToList (string; function ; "¶" );

                    not(IsEmpty($error)) and not(IsEmpty(result));
                    $error & "¶" & result;





            • 3. Re: BUG?? Local variables not always local.

              This looks like something to write up and post in Report an Issue (I'd save myself the trouble of reposting all this by posting a link to this thread in the Issue Report. Report an Issue is intended for posting bug reports after all.

              Have you considered this changes to your second Custom function?

              $error = List ( $Error ; result )

              instead of the case function?

              I don't think that will have any bearing on the issue you are reporting but I think it'll produce the same results with simpler code.

              • 4. Re: BUG?? Local variables not always local.

                List() function...yea

                Nice hint.... I should invest more time in playing around with functions :/

                I just checked the Filemaker BIble by Wiley.


                When no scripts are running, FileMaker deems a hypothetical Script Zero to be
                at the top of the script stack. Therefore, if a local variable is declared while no
                scripts are active (that is, in a calculation expression), it retains its value throughout the file
                whenever the script stack is empty, for the remainder of the current file session.

                So it looks like everybody knows of the behaviour. Guess I have to think of another soultion.

                Thank you :)

                • 5. Re: BUG?? Local variables not always local.

                  Perhaps you can pass the name of the field as a parameter and then use it to declare a global field of the same name via a let funciton.

                  If field is named: QtyOrdered, the variable would be $$QtyOrdered or $$QtyOrderedErrors or some such. That'll take a call to evalutate in order to properly construct the variable name on the fly, but it might work...

                  • 6. Re: BUG?? Local variables not always local.

                    jap, that's an approach. I'll try to do the same with the scriptname.

                    Thanks for your advice :)