AnsweredAssumed Answered

Closed Popovers still exist + perfomance hit

Question asked by mrwatson-gbs on Apr 24, 2018
Latest reply on Apr 25, 2018 by TSGal



  • FMPA 16.0.4
  • MacOS Sierra, 10.12.6
  • MacMini



Before a popover is opened the layout objects within it do not yet exist in the layout - as expected. However:


  • Problem 1 - Popover objects do not go away
    • After opening and closing a popover the layout objects on the popover are not to be seen but continue to exist - unexpectedly,... & unpleasantly, since…
  • Problem 2 - Remaining Popover objects cause extra performance hit



How to replicate + see problem 1


You can replicate Problem 1 like this:


  1. Create a popover containing a named object (in the following example "EML Archivbaum")
  2. In the data viewer use the GetLayoutObjectAttribute function to call up the objects bounds (I used just "top").
  3. In Browse mode check the bounds in the data viewer BEFORE opening the popover.
    • No value => does not exist
  4. OPEN the popover
    • As expected the object exists
  5. Close the popover
    • Surprise! The object STILL EXISTS.
  6. Also after defocussing the popover button by clicking elsewhere => the object still exists.


How to replicate + see problem 2


You can replicate problem 2 by putting objects in the popover that are slow, or which set a $$ variable to show they have been recalculated, and then causing the values to be recalculated by hosting the file and another user triggering the recalculation by poking the records.


In my example where I discovered this behaviour, I have a portal showing (hierarchical) Email folders.

This has a relatively inefficient (relationship) sort, because the folders need to be sorted by a dynamically calculated path which is calculated recursively all the way up the folder hierarchy.

On another machine an email-sync bot syncs emails and stores the last sync timestamp in the folder record ... which in our solution causes the portal to be resorted.


To show that the sort is occurring the sort field calculation contains the following code:


Let( $$Sortierung_NEU =$$Sortierung_NEU + 1 ; "" ) & …the rest of the calculation


This causes a $$ variable to be written when the field is accessed, providing a counter of how often the field is being accessed.


Using this system you can see that the closed portal is nevertheless causing work to be done and thus slowing down the app.


  1. In Browse mode check the bounds in the data viewer BEFORE opening the popover.
    • No sorting as expected.
  2. OPEN the popover
    • As expected the portal is sorted when the portal appears, and re-sorted when the records are changed
  3. Close the popover
    • NASTY surprise! Although the popover is closed the portal not only still exists, but is recalculating and resorting its records as if it were still visible!
  4. Which is the case even after defocussing the popover button


Scope of the problem


While objects on tabs also continue to exist after the tab has lost focus, they do not seem to suffer from problem 2. That also seems to be the case for hidden objects. (…but maybe 'hidden' portals are triggered differently than simple fields… )


=> See attachment TestTabObjects.fmp12


Magnitude of the problem

While this behaviour may not represent that much of a problem in layouts, where maybe one or two wimpy fields or portals are displayed in popovers, it can in other cases  represent a considerable performance bash.


Given that we, and other developers, have taken the opportunity to overhaul and optimize old layouts using the latest tabs, popovers, sliders and hide calculations to create more functionality on a single layout whilst removing unnecessary, distracting (and potentially 'heavy duty') functionality from the layout, it would be good


  • if the behaviour of hidden popovers were optimized and
  • this behaviour were documented (bug or feature?)



Together with the fact that the Layout mode case statement 'leaks' in hide calculation


  • unexpected performance hits are quite possible in layouts
  • and damn difficult to debug + find!



Workaround (if any)

Use card windows instead of popovers, where possible - Particularly where the contents can cause a performance hit even when closed/hidden.