Yes it is.
If they are on a pop-over: no. Tab panel and slide panels: yes.
If I may ask a slightly different but closely related question...
Are objects displayed according to a 'Hide object when..' calculation evaluated if they are not displayed? For example if a section of a layout included slow unstored calculations or summary fields, and you wanted to display this section optionally (using the Hide object feature), would any of the calculations be made in the background (even if not displayed).
Generally, is there any significant overhead in having many conditionally-displayed objects on a layout (in effect, to create a somewhat dynamic layout, whether or not slow calculations are involved)? Obviously FM would need to do some extra work to decide what to display, but I would expect this to more or less insignificant (unless extra layout objects are needed anyway - albeit superfluously unless the 'hide' calculation changes).
In relation to your comment that not-displayed tab panel use resources, does FileMaker 13 work differently to FM11 in this respect? In FM11 I often use a tab panel at the bottom of a list of numbers to enable users to see summaries only if they need them (by switching to the tab with the calcs/summaries) - to avoid unnecessary delays. Long ago I used to use the 'invisible portal' trick to achieve a similar result; again, it was clear that non-displayed calculations were not evaluated.
My understanding is that hiding is a form of conditional formatting, and that FM must evaluate the contents in order to determine whether the hide/format condition is met. (see FTS_Advanced for FileMaker 13.pdf page 3-106)
I looked at the page you mentioned but wasn't sure what part you were referring to. I couldn't see anything to suggest that FM evaluates calculations whether or not their evaluation is required.
I ran a simple test from which it seems that FM doesn't evaluate calculations for non-displayed fields. I created a summary field which took a few seconds to evaluate. The (unstored) calculation field it summarises depends on a global number field. I formatted this global field as radio buttons with a value list of a few numbers - so clicking the radio buttons would force the summary field to recalculate.
With the summary field displayed in the the normal way, I could only click the radio buttons every few seconds. This was also the case if the layout included a field with conditional formatting which referenced the summary field.
Where the summary field was within a non-displayed tab panel, popover, portal or tooltip, or where the field was hidden, using 'hide object when', I could click the radio buttons as quickly as I liked. Clearly the non-displayed summary field was not being evaluated. I think this is all as it should be, and as I would hope it would be.
It makes sense that the conditional formatting case is different to the others. I'm glad that 'hide object when' doesn't seem to be a form of conditional formatting, at least based on this simple test. I can't think of a good reason why it should be.
I'm still curious about Wim's comments and generally, if 'hide object when' does have any significant impact on the speed at which a layout is redrawn. Obviously it has to evaluate the hide calculation which might typically use a global or variable, but this hopefully wouldn't add more than a few milliseconds of delay.
There is a thread related to the questions you are considering in your contributions to this thread (regarding if/when overhead is incurred for hidden layout objects):
It is an interesting topic, and I note that the conclusions that you may be reaching are somewhat distinct from the conclusions reached in the other thread.
If I understand correctly, the one point where everyone seems to agree is that items in popovers do not incur overhead until/unless the popover is displayed.
Hope you find this interesting.
And we have to make the distinction between a couple of "under-the-hood" actions that FM does.
Portal data gets loaded on inactive tabs/panels even if you have no unstored calcs or summaries on them. Summary and unstored field calcs are different: those get calculated when they are shown. That's different than the background loading of related data.
I have not done much testing on the visibility condition but my guess is that it triggers very late in the layout rendering so I would not use it as a performance optimization tool. Whether you want to conditionally show or hide things, optimize for speed long before making that decision.
A slightly old thread, but three separate DevCon sessions this year shed some new light on this. Two “themes under the hood” sessions, as well as the following day’s performance panel, all presented essentially the same model for loading non-visible objects, including portals, and their data.
As I now understand it, hidden tab panels, slide panels, and popovers are identical in using a “lazy loading” (Andrew Paulsen’s term) model. The objects are drawn, but their “views” are not built (meaning the data is not fetched) until displayed. Per Paulsen, offscreen objects have “less cost” than onscreen ones, and objects in hidden panels (tab or slide) or popovers have even less cost. The point was reiterated in the performance-panel session (with several FM engineers present) that they skip building views for non-visible objects, and that includes panels and popovers alike.
Of course, the caveat is that if any related data is shown or referenced on a visible part of the layout, then the related data is fetched (entire rows at a time) when the parent record loads.
Hope I got that correct, but I made pretty detailed notes each time the issue was raised in a different session, and they all were in agreement. It certainly surprised me.
P.S. Wim - enjoyed your deep-dive scripting session tremendously.
This is very helpful and reassuring - thanks. This is certainly my experience (and what I would hope to be true) but the opinions on the subject on this forum, in this thread and others, vary. What you learnt at DevCon certainly seems logical. Perhaps the caveat you refer to is the cause of the confusion and variation in expericence.
Many thanks for your comments, and for the useful and interesting link. I'm sorry I didn't thank you before - I went off on holiday and forgot about it.
The thread you referred to was particuarly interesting in the light of what Mark heard at DevCon. I think it's a critical topic; it's surprising there are different opinions and experiences amongst developers here.