AnsweredAssumed Answered

Layout mode case statement 'leaks' in hide calculation

Question asked by mrwatson-gbs on Mar 12, 2018
Latest reply on Mar 15, 2018 by TSGal

Hardware/Software

 

(Tested on) Mac OS Sierra 10.12.6 ... but prob. all OSes

(at least) FM13 thru 16

 

Issue

 

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:

 

Case(

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:

 

  1. a stored calculation,
  2. an unstored calclation,
  3. a global calculation and
  4. a control field.

 

On the layout there are the  four fields with corresponding hide functions:

 

Case(

TestCaseStatmentBugInLayoutCalculations::Always1_stored ; 1 ;

Let( $$ThisShouldNeverBeExecuted_stored = $$ThisShouldNeverBeExecuted_stored + 1 ; "" )

)

 

 

 

Case(

TestCaseStatmentBugInLayoutCalculations::Always1_unstored ; 1 ;

Let( $$ThisShouldNeverBeExecuted_unstored = $$ThisShouldNeverBeExecuted_unstored + 1 ; "" )

)

 

 

 

Case(

TestCaseStatmentBugInLayoutCalculations::Always1_global ; 1 ;

Let( $$ThisShouldNeverBeExecuted_global = $$ThisShouldNeverBeExecuted_global + 1 ; "" )

)

 

 

 

Case(

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':

 

 

 

Steps

 

  • 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

 

 

Expected result

 

NO variable should appear in the data viewer, since the let statements should never be reached

 

Actual result

 

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.

 

Analysis

 

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.

I guess it has only come to light now, since we have just (very carefully and with an eye for performance optimization) created a more dynamic / responsive layout which has had unexpected performance problems.

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

Outcomes