The last layout the was on file when it was closed before it was hosted is the first layout that will be displayed. This actually happens on the desktop it just happens faster so you might not notice it. just unhost it, open in in FMP go to the layout you want it to open on and close the file.
Thank you for your response. I certainly follow your thinking.
However, my solution will be hosted (via RapidHosts) and accessed by six iPhones/iPads plus at least three Macs, ad hoc. In other words, there's no predicting which device will next open the database... Is there, perhaps, a script step that would allow the system to do the device check *before* opening a window (as a perminent fix)?
Thank you again, John.
Sorry for not being clear...Before hosting make sure when the file is closed on the opening layout. Once hosted it will not change.
I think this happens because the opening script will run 'on first window open' opening to the last layout it was closed on when not hosted before the script can navigate to the layout you want.
I think it might be me who's not being clear. Apologies.
The opening layout will need to be different, depending on the device being used to access the database. For example:
- I'm in the office, working on the Mac, and I open my hosted database using FM12 -- my opening script tells it to open on "DesktopLayout"
- I then go to a client's office, open the same hosted database using FM Go -- my opening script tells it to open on "iPadLayout"
As I said previously, this functions perfectly well. But in the scenario above, when I open the database using FM Go, it flashed up "DesktopLayout" before going to "iPadLayout". It's this "flashing", I'm trying to eliminate...
I hope this clarifies things a little? And again, thanks for your help.
1 of 1 people found this helpful
Ah, what i do is create an opening splash layout. So it always opens to that layout then the script takes over and navigiates from there...
I usually put on the layout
Opening System My Database System....
One Moment Please....
The OnOpen script will resize the layout and pause for a second or 2 them move on...
Thanks for this -- very helpful. I will implement this in my final database.
Am I to assume then, that there's no "fix" for this issue within the script itself?
Impossible to say. We have not seen your script.
This really isn't broken so the 'fix' is to understand the behavior. Apparently the database needs to open to a layout and does so before firing off the script.
It's not generally seen on internal networks because it happens very fast. This 'flash' of a layout has been present since at least FM 10.
Understood, John, and thank you for your help with this.
I'll implement your suggestion of a splash layout.
Actually, Bruce, if you look at my original post I said that I followed this helpful tutoral to the letter. This is the script:
If [PatternCount ( Get ( ApplicationVersion ) ; “Go_iPad” ) = 1]
Go to Layout [“iPad_Home” (HOME)]
Else If [PatternCount ( Get ( ApplicationVersion ) ; “Go” ) = 1]
Go to Layout [“iPhone_Home” (HOME)]
Go to Layout [“Home” (HOME)]
Do you have any suggestions that might help?
Under File Options... there is a choice to set an opening layout. Choose your Splash layout there.
1 of 1 people found this helpful
When a client opens a hosted file it receives the 'default' layout before anything else. FMP must open the file to a layout, must then download the layout list/scripts/custom functions/DB schema, etc., and then determine which layout to switch to and which script to run on first window open.
Without all that information the FMP client has no context as to where you are or what to do.
I suggest during development you add a closing script that always goes to your "Opener" layout, edits something so the change is recorded, and then close the file.
Just changing layouts before closing does NOT guarantee it has become the default layout. Changing layouts is not something that triggers saving file to disk. You must do something to the file that requires a save to disk operation. I think the Flush Cache script step may work for you in this case.
The opinions expressed in this email are my own and do not reflect those of my employer or anyone else.
Ch0c0halic, FileMaker 12 Certified Developer
Many thanks, Ch0c0halic, for a really useful and informative response.