Efficiency of tabs and Performance Impact

[mr_vodka]

I had a question that I had been wondering about for a little while now...

How does the tab panel load the information for the end user. Obviously if you take a tabbed layout and open it in FM7, it will display all the fields overlayed ontop of each other. So does the data load when the fields on each seperate tab is displayed or does it load when the layout itself is displayed?

I started thinking about this and how it would effect performance on lets say something like 20 tab panels with 50 fields on each panel.

[JesseSFR]

That sounds like a great question for the tech guys at Devcon. I think a interesting test would be to put a summary field of thousands of related records on a tab that isn't showing when the layout is loaded. See if you get a progress bar... if you do you have your answer.

If I had to guess, they probably load all the data at once.

[mr_vodka]

Yeah I guess I will ask the guys at DevCon. Are you guys going to be there?

[JesseSFR]

Yea we'll be there.... I think we will be at the FileMaker Magazine desk for a couple hours each day answering questions.

[Razumovsky]

I poked around on that same question a few months ago and found that looking at the layout xml for tabs was a helpful beginning:

The visPanelIndex is where the value is stored for the default tab to be displayed (the one last selected in layout mode). This likely tells the rendering engine which subsequent tabpanelobj (and all fields nested within) to render, ignoring all xml nested within any other tabpanelobj tags with the exception of the tab names used for display on the top tabs.

So, the only real load of 20 tabs would be the effort of rendering the default tab (and all 50 fields within), the 20 top tab labels, and the storage of the additional xml text somewhere (stored once for the layout, very small amount of text data). None of the fields on the non-displayed tab panels are evaluated.

One manner of testing this is to create a repeating unstored number calc:

Let($$rep=get(calculationrepetitionnumber); $$rep)

and then putting a separate repetition on each tab panel. As you click between the panels, $$rep shifts in value to the repetition being displayed on the current active tab, indicating that it is the one being evaluated. This could be just because it determines which repetition is evaluated last, but unlikely. To test, we can set the default tab to one without a repetition and then clear the $$rep variable. It will remain blank until a different tab panel with the calc field on it is selected (at which time the calc will evaluate only for that repetition). As unstored calcs are only evaluated when called, this would indicate that only the fields on the visible tab panel will be called.

FM7 likely displays/evaluates all the fields overlapping as it does not recognize the TabControlObj tag (or the nested TapPanelObj ones), so just ignores them and proceeds to the next lines of xml- where the field objects are. Since the FM whizzes are so good about well forming their code, everything elses except the tab object gets displayed exactly as it should.

Once you get a handle on their quirks, Tab panels can be a great development asset. I am finishing up a solution at the moment that uses basically 2 layouts to display data from 15 or so tables, with customized details/Fields/portals for each table. There has been no noticeable performance delay.

-Raz