Hide object when - calculation cost in master-detail portal

There is the very useful 'hide object when' in 'Layout Object - Behaviour'. On of the most handy FM features, I am using on almost every layout. Recently, I observed a degraded responsiveness on a layout with a portal. Inside the portal, field objects calculate if to show or to hide.
The hide calculation invokes a somewhat larger custom function. The increased waiting time (about 0.5 sec) made me curious and I am trying learn how FM handles invocations of 'hide object when'.
A typical case is a field box in a list layout or portal. The box has a calculation for the hide condition.
How to peek into FM's inner workings, within a CF? Global variables are handy and provide details about what is going on inside the CF.
In found set, 'hide object when' is invoked when, for example the active layout changes, the found set changes etc.
Having a found set of 20 records with 1 field box in each line that invokes the CF in a 'hide object when' calculation, I would expect 20 calls of that CF.
I got 78 calls.
The attached sample file provides some more details. Why is the number of calls of the CF significantly higher than the theoretical number (number of objects calling the CF x number of lines ) in 'hide object when'. What's the reason behind?Test.fmp12 (640 KB)

1 Like

I think it's excellent to be aware of this.

I recall that when v.12 was first released, FMP Devs were discovering that calculations for conditional visibility and/or formatting were being evaluated far more often than we would have hoped, and there was similar testing going on. To FMI's credit, they put a lot of work into improving the efficiency of this, and reducing the number of calculation evaluations, but I don't think that the numbers ever dropped to the theoretical minimum.

About five years ago I went out of my way to write certain custom functions in a way that would cache the last inputs and associated returned values, so that multiple calls with the same input could be resolved faster, but in retrospect, I do not think I would do that again. The code was sound, and it did noticeably improve some portal scrolling performance, but it made for code that would just be a headache for any subsequent developer to have to grok, and I no longer feel that I made a good call on that.

A much more sensible practice (which I believe, @Torsten, you are probably already doing), would be to utilize object grouping anytime that the same conditional hide expression applies to multiple objects which can be grouped -- and then place the hide condition on the group, instead of the individual elements.

Why more evaluations are executed, I could not say. On a less serious/practical note, the first thing I thought of when I read this post was that layout objects and the layout redraw process have a similar relationship as some parents and their kids:

  • Child [LayoutObject] : "I'm going out to play." --> "I need to redraw."
  • Parent [RedrawCode]: "Are you hungry?" --> "Do you need to be hidden?"
  • Child[LayoutObject]: "No." --> [Evaluates Calculation expression]
  • Parent [RedrawCode]: "Are you sure you wouldn't like something to eat first?" --> "Do you need to be hidden?"
  • Child[LayoutObject]: "No." --> [Evaluates Calculation expression]
  • Parent [RedrawCode]: "How about just a quick snack?" --> "Do you need to be hidden?"
  • Child[LayoutObject]: "No." --> [Evaluates Calculation expression]
3 Likes

@steve_ssh, excellent child-parent metaphor :slight_smile: :clap:
I looked at the vendor's customer support site but could no find any of the old posts about 'hide objet' recalculation and performance. So thank you for the retrospective and perspective.
I really wonder what triggers so many re-calculations of the 'hide object when' condition in the simple case of moving to the next record in a found set.
Too many of these re-calculations at the wrong moment make it difficult to use that very nice feature in more complex layouts.

1 Like

Well, I think everything that causes a redraw of the window has to trigger the hide-condition. I would ask for the situations that lead to a redraw.

2 Likes

Good question, @mipiano. A list of trigger events would allow for an assessment and suggestions for improvement.

@Torsten , your layout has a portal of thirty rows and your script has five steps that have the potential to trigger refreshes.

I created a new layout, in list mode, and placed your UUID field on it. Running the script in list mode without a portal there are only 6 CF calls reported.

@Malcolm, the counter is set to zero just before the go to next record step. After that step, no more calls appear, which I checked in debugger.
It is a master-detail portal, no relation to other TOs. Why would displaying the same data in a master-detail layout trigger so many more calls, compared to list view?

The calculation is placed on the field. Each time the field is displayed it's hide/show status must be evaluated. For each record that is displayed, all thirty portal rows are called and evaluated.

You script is creating a lot of redraw possibilities:

Show all records - with a master detail portal that change in the found set will trigger a redraw of the portal. FileMaker does some pre-caching, so it will definitely evaluate the thirty visible rows in the portal and a couple dozen more.

Omit multiple Records - again, the change in found set will trigger a redraw of the portal.

Show omitted - again - as above

Go to record next - new record context but same found set. Depending on how FileMaker handles this it may or may not need re-evaluation.