(Tested on) Mac OS Sierra 10.12.6 ... but prob. all OSes
(at least) FM13 thru 16
Edited 2018-03-12 MrW: New demo file inc. conditional formatting => seems to really only be a problem in the hide calculation => Title renamed, text + images corrected
Edit 2: attached demo file V3
Edit 3: attached demo file V4
FileMaker seems to handle calculations in layout hide calculations differently compared to calculations in fields,
...OR - putting it another way - (due to multi-threaded layout rendering? mm, no) stored calculated values are not being referenced properly / loaded in time, so that case statements referencing stored values are not exiting appropriately and thus executing calculation parts that should never be executed.
Specifically, in a case statement of the form:
condition1 ; result1 ;
condition2 ; result2 ;
condition2 should not be calculated - or even considered - if condition1 is true.
HOWEVER, in a layout where we have particularly heavy condition2+ (after a lightweight condition1), we are seeing unexpectedly heavy performance hits, apparently due to condition1 not kicking in when it should do.
I have created and attached an example file to demonstrate this.
In the file TestCaseStatmentBugInLayoutCalculations_V2.fmp12 there are four fields:
- a stored calculation,
- an unstored calclation,
- a global calculation and
- a control field.
On the layout there are the four fields with corresponding hide functions:
TestCaseStatmentBugInLayoutCalculations::Always1_stored ; 1 ;
Let( $$ThisShouldNeverBeExecuted_stored = $$ThisShouldNeverBeExecuted_stored + 1 ; "" )
TestCaseStatmentBugInLayoutCalculations::Always1_unstored ; 1 ;
Let( $$ThisShouldNeverBeExecuted_unstored = $$ThisShouldNeverBeExecuted_unstored + 1 ; "" )
TestCaseStatmentBugInLayoutCalculations::Always1_global ; 1 ;
Let( $$ThisShouldNeverBeExecuted_global = $$ThisShouldNeverBeExecuted_global + 1 ; "" )
1 ; 1 ;
Let( $$ThisShouldNeverBeExecuted_control = $$ThisShouldNeverBeExecuted_control + 1 ; "" )
plus4 fields with similar conditional formatitng functions
Note: All of these layout fields are correctly rendered:
However, the case statement referencing the stored field is 'leaking':
- Open the example file (V4) and open the data viewer
- Browse through records, or
- create records, or
- Switch between layout + browse mode, or
- 'touch' the field definition of Always1_stored
- observe the data viewer
NO variable should appear in the data viewer, since the let statements should never be reached
As you can see, in the case of the stored calculation field, the let statement is being reached, and the variable is being incremented .... approx one for each displayed record ... but the behavior is chaotic/not predictable ... scrolling increments the number only SOMETIMES ... creating a new record also only sometimes.
Generality of the issue.
I'm told that cond. formating suffers from the same problem but have not tested myself.
See attachment V4 => It is NOT a problem in cond. formatting.
I HAD thought this is an (internal) error in the new multi-threaded rendering of layout contents .... but the problem seems to also exist in single-threadeed layout rendering versions ... in all FileMaker Versions I tested back to 13.
Workarounds - Partial, unpleasant, tempoarary
- Define fields in your tables to contain the hide calculation GUI Logic - these seem to always be processed correctly.
- Use UNSTORED fields instead of stored fields, WHERE POSSIBLE (which isn't always) - these seem to be referenced properly.
Looking forward to your reply TSGal et al