A quick test doesn't seem to confirm this (defined several $$vars with label lists, then calculated the value per segment using Evaluate() and the layout name).
Anything unusual about your $$vars, or your label calcs?
Is the delay in the rendering of the layout after arriving there, or until the switch is actually performed, i.e. remaining on the source layout? (The title suggests the former, the description the latter.)
There are 8 global variables in the nav bar, plus more in two pop-ups (I'm not thinking that these pop-ups affect speed, but I haven't tested). These variables are set at initial log-in, so there's nothing too complicated about them. They are simple labels.
Also, this is a hosted file (WAN), so I'm sure that if it were not hosted or LAN, none of this would be a problem.
The delay occurs before we see the new layout -- you sit on the original layout for a couple of seconds. But the problem is definitely with the destination layout.
Confirmed -- if the global variables are on the pop-up, there's not a problem.
Have been using $$var for 2 level for nav for years, never encountered such issues.
<<Do we have to give up on global variables on layouts?>>
Don't have to, but suggest you look at Button bars and navigation layout parts in FMP14; you don't say what version you are using, so this may not be relevant.
the button text can be calculated
Conditional format on individual buttons just as $$var buttons
can expand the width of segments uniformly land the whole button bar with simply drag ( like repeat fields), rather than resizing and re-spacing multiple $$var buttons
no more $$var occupying space in the Data Viewer
Thinking ahead to when defining a single navigation part that can be seen across multiple layouts ( rather than replicated on multiple layouts); I suspect the new button bar and layout part will could be foundational parts of that implementation.
I am using 14, but I might have some users who are still on 14. But I think I figured out the problem: conditional formatting. I don't know whether it's conditional formatting in general that slows things down, or my calculation:
selectedmodule = $$label.1;
valuenumber = PositionValue ( $$captions ; selectedmodule ; 1 ; 1 )
GetLayout(Substitute(MiddleValues ( $$listviews ; valuenumber ; 1 ); "¶"; "")) = Get(LayoutName)
GetLayout(Substitute(MiddleValues ( $$mainviews ; valuenumber ; 1 ); "¶"; "")) = Get(LayoutName)
I use 2 $$var sets, one for main modules ( c. 10 modules) then another set for sub-module layouts; for the button (module) names
the module is passed to the script as a simple number, same for the sub-module
so the main $$_nav1 is a single number set by the script, from the SP (number) on the $$_nav_n global buttons, and the go layout is a conditional If sequence
If $_sp = 1
else if $_sp = 1 = 2
then the CF on the main nag buttons can be a simple If $$_nav1 = n
same on the sub-module buttons, CF: $$_nav2 = n
As the buttons are $$_var, the text values can be set per module by the navy_secondary script
I suppose that you have both navigation and content on your destination layout.
Duplicate it, remove all content and only leave navigation on it. Go to it. Is it still slow ?
Things like tab controls / slide controls on your layout, unlike popovers, do load all the data they are meant to display, even if it's not on the front tab/slide.
PS GetLayout() used in your posted calc is not a native FM function. I presume it's a custom function. Depending on how it is implemented, slowness might appear.
I've a navigation bar with 12 top and 12 sub navigation buttons all global vars.
Filemaker seems to first load the data then draw the layout, so how much data is displayed will make a difference.
Is the delay the same on every layout?
Simplifying the calculations for the conditional formatting solved the problem!