5 Replies Latest reply on Mar 25, 2011 3:49 PM by philmodjunk

    Inconsistent Updates of Global Variables in Merge Text

    philmodjunk

      Summary

      Inconsistent Updates of Global Variables in Merge Text

      Product

      FileMaker Pro

      Version

      11.02

      Operating system version

      Windows XP SP3

      Description of the issue

      While a let function such as Let ( $$Count = table::sMax - table::sMin + 1 ; 1 ) that is part of a conditional format expression can be used to assign a value to a global variable, the variable, when displayed as merge text does not consistently display the expected value. Either the screen is not updating consistently or the let function is not updating the value consistently.

      Steps to reproduce the problem

      A demo file may be downloaded from: http://www.4shared.com/file/qh0m_zey/LetFxGlobalVarUpdateDemo_2.html

      If the file is just opened or the layout is accessed after a script performs a find to pull up a different group of records, the merge text will display a past value until the user interacts with the window in some small way such as hiding/revealing the status area or rolling the mouse scroll wheel to move to a different record.

      Expected result

      That the global variable will display the correct value.

      Actual result

      A past value is displayed.

      Workaround

      If you include script steps to first refresh the window then change to a different record (See second "fixed" script), the variable will update correctly.

        • 1. Re: Inconsistent Updates of Global Variables in Merge Text

          PhilModJunk:

          Thanks for posting!

          The behavior of merge variables not immediately refreshing after being updated (on both Mac and Windows) had previously been reported and is currently being investigated by our Development and Quality Assurance departments. I've attached your post to the original report and will post here with any updates.

          TSBear

          FileMaker, Inc.

          • 2. Re: Inconsistent Updates of Global Variables in Merge Text

            PhilModJunk:

            I've been notified that the current design of merge variables is to behave similarly to unstored calculations. Meaning, there needs to be some sort of action to force them to be retriggered. A workaround suggested was to add a script trigger to the necessary fields that refreshes the window on exit. 

            TSBear

            FileMaker, Inc.

            • 3. Re: Inconsistent Updates of Global Variables in Merge Text
              philmodjunk

              I'm well aware of the work arounds. Part of my little experiment that brought this issue to light was to try to keep the use of script triggers to a minimum just as a general application of the KISS principle as well as to avoid using a calculation field for this.

              The suggested work around cannot be used on my demo file as there are no necessary fields to which the trigger could be attached. The value computed and stored in the variable is only changed by changing the records selected for the current found set--a found set generated by the script that pulls up the report in the first place. (It references the value of two summary fields.)

              The work around script in my demo file does not have this limitation and shows that refresh window, at least on initial access, fails to update the global variable (or at least its displayed value). It has to refresh the window AND then manipulate the view in some small way before the variable updates. If you check out the script, you'll see that it first refreshes the window, then uses go to record to change to a different record and then back again. If I reverse the order of these steps to put the refresh window step last, the variable does not display an updated value. That behavior seems very "bug" like to me.

              This demo file, by the way, has been abstracted from a real world application in one of my files. In the original file, the values computed by the max and min summary fields are on a field that records the corresponding pre-printed tag numbers on NCR receipts that we print out. By comparing the results of this calculation to the found count of all records for a given printer, we can confirm that no numbers in the sequence were omitted from the report--something that keeps our auditors happy.

              • 4. Re: Inconsistent Updates of Global Variables in Merge Text

                PhilModJunk:

                I apologize, I misunderstood your original post. After further testing with your file, I do see the behavior you're referring to and agree that it doesn't seem right. I've forwarded your file to our Development and Quality Assurance departments for further investigation.

                TSBear

                FileMaker, Inc.

                • 5. Re: Inconsistent Updates of Global Variables in Merge Text
                  philmodjunk

                  Since the last time I posted here, I played around with this some more.

                  Set up a simple expression in the conditional format:

                  Let ( $$GlobalVariable = Table::Field ; 1 )

                  Specify a field, such as a serial number field where the value is different on each record. Now move from record to record and watch the globalvariable update as you move from record to record. The variable seems to update as you exit the record thus displaying the value from the previous record instead of the current record. That might actually be useful in some cases. (To capture the name of the last layout visited, for example), but I wouldn't use a "bug" that should be fixed for something like that as a future relase or bug fix might well modify this behavior.

                  One reason for playing with such a conditionally formatted merge field is that you can modify the layout of a hosted file by adding this setup with a calculation expression copied from a field definition to examine how portions of the field's calculation are evaluating on different records without having to open Manage | Database and possibly lock all the records in the table at the wrong time.