I have a data base with several layouts. It is hosted in FileMaker Server 12.
A startup script makes the user go to "LayoutC" but, when the file is open, FMS shows another layout (LayoutB or LayoutD) just for one or two seconds. Then, it goes to LayoutC.
Is there any way to avoid this?
Yes. Take the file off the server. Open it and go to the layout C. Enter layout mode and make a small change then save and reload the database to the server.
Behavior for layouts in the server environment is similar to the global fields.
Before uploading file, you must close the file as you would like to find the first time that you open in server environment.
Now it works.
Thank you Malcom and Fabietto for your quick reponse.
Under File-->File Options... set the When opening this file --> switch to layout option to Layout C. Even better would be to go to an "Opening..." layout and in your startup script, Freeze Window so the user just sees a nice layout. I include my logo, the file name, etc on that layout (and have one for "Closing..." too).
David may not be an opening pitcher,
That won't solve this problem. FMP shows and uses the layout "used when closed after a change" before it does any of the startup options.
Now if you'd said put this in the "Close" script I'd agree.
chocoholic may find this post bittersweet...
My suggestion will solve the problem. I'm guessing you haven't actually tested your assumptions. You could try this...
Set the File Options to switch to Layout A on opening. Put a conditional formatting calc that sets a global variable on a Layout B. Close the file while on Layout B (or add a window close script that goes that that layout). Open the file and you get to Layout B and the global variable is not set. It was never evaluated because that layout never loaded.
David may be serving chocolate (yummy),
Try opening the test file over a high latency (slow) WAN. You'll see the first layout shown is the one the File was closed on, regardless of the File Options. However, it will remain blank. You can also put a field from a related file on the last closed layout and it opens the related file even though no other layout or script in the DB references the related file.
There was a long discussion some time ago on the topic of opening related files unexpectedly and much testing was done. The testing by me and others reliably supports my conclusion.
While I haven't gone back and tested this in FMP12 the described behavior is identical to what we saw over a high latency WAN in FMP11.
ch0c0halic is correct, David - you can also verify this if there is an opening script on file. Open the file with the script debugger on - and you'll see it does go to the "wrong" layout BEFORE it does the File Open layout step.
On a fast, LAN connection, this is invisible. But it is very disconcerting to see on a WAN.
For this reason - I set all my closing scripts to check and see if I am running a file on the server. If I am not (local file) the closing script goes to the layout I want to start on before closing. That way when I put the file on the server, I don't inadvertently close it on the wrong layout. I also have a step in the same closing script that checks for data in globals that shouldn't have any. How many times I have been testing a report or a portal that has allows the user to set parameters using a global field, and forgotten to clear it, so I either have to add a set field step to clear it at the beginning or end of every script that uses it (slowing things down).. If the file is hosted - clearing the globals is a waste of time - but if it is local, it allows me to make sure I upload a "clean" set of parameters for the users.
Sorry, but choco is not correct.
Perhaps we're having a disagreement about what it means to "load a layout" or the nature of bypassing the default layout.
Simply put, when the "default" layout is bypassed by a "Switch to layout..." (not a "Perform Script...") in the File Options, the following is true:
-Picture graphics don't load
-Script triggers don't fire
-Conditional formatting doesn't evaluate
-Record data doesn't cache
-Portals don't load
-Unstored calcs don't evaluate
-External file references don't open external dbs
What aspects of a "layout loading" that you're thinking of that do occur? Can you provide a demo file?
You can look at my slapdash file here:
With the provided Full Access privileges, you can turn "Switch layout..." on and off and change the default tabs on the "default" (Slow Load) layout to test all of the above.
David may not have the right test equipment,
Yes, external file references are resolved and external files are opened. Many of us have tested this extensively in attempting to prevent the 'unexpected' file load.
I have to ask, since you are so adamant, do you have a slow WAN to test this on and have you tried to reproduce Javier's symptoms? I have and it is exactly as he says. The 'first' layout flashes and then it switches to the one in the preferences.
When a file is opened FMP has to do several things. Not necessarily in this order.
1. load the file structure, tables, relationships, value lists (not necessarily the data in the list)
2. load layout structure
3. load a layout, some things cannot happen in the file until a layout is loaded to get the context.
4. load the scripts (cannot run a script until the layouts and the context are known)
5. load index for the found set (may also have to occur before running the startup script)
6. possibly some other things I've forgotten
At some point it has enough information to perform the startup options. However, by then it already has partially displayed the first layout. It doesn't load everything on the layout but it definitely shows it. And must resolve relationships in order to establish the context for the startup script.
So basically the file has to be loaded (opened) before anything can be done with it. Over a LAN or a fast WAN these things happen so fast you don't see them. Over a slow WAN you do see the first layout flash on screen before the file options are performed. Even if the file is closed with the layout off-screen at shut down the window is shown on-screen and in that case full screen. This is making sure the file can be opened and used.
While it may be true that the layout doesn't "load" so script triggers don't fire, that wasn't the question. The question was how to avoid the flash of the wrong layout when opening on a slow wan. While you avoided that issue with your test file, since there is no opening script (which I believe triggers before the default layout load), I don't think this is really a good demo of the problem. With an opening script you are far more likely to get the flash. It's pretty rare that I have a database with no opening script. YMMV.
David may not have the right test equipment,
do you have a slow WAN to test this on
On my laptop (Mac OSX) I use a preference pane called "Speed Limit" which can throttle the network on selected ports.
Of course, it is even easier to use an iPhone or an iPad on a 3G connection. Then you can watch the the screen lag at your leisure