Yes Jeff, this is tricky and it took me a while to get this set up properly.
I have solved this as follows:
- all UI files have only 2 accounts, an autologin as guest and a developer account
- obviously the guest account is completely restricted, including custom menus
- the opening script in the 1st UI file opens to a blanc layout w/o any data connections and all UI files as hidden and to a blanc layout and exit their openings scripts immediately, setting a global $$open=1
- then the data file is called which will ask for credentials (or quit application when this fails)
- when credentials pass, the opening UI file now moves to a layout with data connections
- the opening scripts in the UI files are called again, bypassing the first exit because $$open=1 and completing the rest of the opening sequence
- developer account will then do a seperate script to open all files with FullAccess
An additional advantage is that your account maintenance is limited to the data file only
I'm not completely sure, but I believe an FileMaker external data source that has a TO on the relationship graph will open when the file opens, regardless of a lack of referencing layouts and script references.
However, if you have no TOs, those files won't open unless you either, a) open them explictly with an Open File or call a script in a remote file.
One way around this would be to have TWO interface files. An Opener and your regular Interface. The opener file would have all the same data sources, but no TOs. You have an opening script that takes the credentials in a custom dialog and then opens all the remote files that have TOs in the Interface file. Then, open the Interface and close the Opener.
FMP opens any file it needs to access for data/scripts. If the file is not needed for access then it will not be opened.
If the file uses a layout that has related fields then FMP will open the related file. The problem is you won't see the "First" layout on a fast network. You need to 'define' which layout is used when FMP opens to avoid the automatic opening of a related file.
See this discussion to find out more on the 'First' layout used and how you can define it.
And from a discussion "Openings behavior" on the FMPExperts list 12/5/2011.
Simple yet not so obvious.
1. On Open FMP must first access the file. When it does it receives the 'current' layout information. This is before any script, go to layout on open, or anything else happens. FMP must know where to start.
2. This default layout is now used to open the file and create a window, can't have a window without a layout. Critical: the layout information is acted upon. After all it is the active layout! Related fields are resolved to open any required files, etc. All the normal things FMP does when going to this layout.
3. FMP goes to the on-open preference layout.
4. FMP runs the on-open script.
Guess what? If this is a really slow WAN you can actually watch FMP do all of these things. I've seen the default layout draw on screen and then suddenly disappear as FMP progresses to the next opening process. Closing the DB with the window off-screen does NOT work. FMP will automatically reposition the window to on-screen when it opens. This is a necessary requirement of the opening process because you can't have the file open and no way to get to the current window. You also cannot make the window really small. There are limits. Your best bet to control the opening process is to have a blank layout, no fields, and possibly even connected to an empty table (no fields) as the default layout. Default layout is the one the file was closed on when hosted by FMP/A - not FMS.
Thanks all for the pointers and great suggestions! What I ended up doing was to tighten the restrictions of the UI file's [Guest] account so that it could only access the splash screen layout. That way, even if it starts on another layout (thanks for the link and the info about setting the 'first layout' btw), since he has no permission to see or do anything from there, the file(s) aren't opened.
I found, however, that even though this worked when opening the file, it still tried to open several external data source files when I tried to close it. (An unsuccessful login would tell the script to close the file, which brought up a login dialog for the related file(s), even though I hadn't changed layouts. I'm still perplexed by why this is, but managed to workaround it by issuing a "Go To Layout[somelayout]" command just before the Close File command, to take the user to a layout to which he did not have access. This similarly prevented the external files from trying to open.
Thanks again! Sometimes all you need is some good ideas to kick the right synapses into gear.
Some of this information is incorrect.
I did some testing and found a couple interesting things.
One, is that the "Go to Layout" option in File Options will skip loading the "default" layout (and not open external file references). A triggered "On First Window Open" script will not.
The second thing is a file's default layout is not the last layout visited before closing. I thought that was the expected behavior, but it's not (anymore?). In order to get a new "default" layout to stick, you need to change the layout, make a change in Scripts, Layouts, or Tables, and then close the file. Or just bypass the whole thing by using the File Option..
DavidJondreau wrote, in part:
It's been my understanding that these changes have to be made on the unhosted file, before they truely stick so that the hosted file will default to the correct layout.
I've done this by making sure that all file settings include either a goToLayout onLastWindowClose, or a "closing" script which takes the user to the intended layout for default opening before I close it in single-user unhosted mode, prior to putting it on FMServer.
I was not aware of this changing with 12 to allow default layouts to be changed during hosting. (Can anyone verify such a change? It sure would make things easier to fix on the fly.)
Sorry, didn't mean to mislead you. I had only tested local files, you must still take it down to change the default layout. Except you don't. Just set the Switch to Layout... dialog in the File Options. Then there's no need to worry about this.
Interestingly, if you do your technique, with a Last Window Close trigger, FileMaker saves that layout as the default.
But if the default is Layout A, and you run a script to go to layout B and then close the file (with no script trigger), well, that does not set Layout B as default.
Thanks for clarifying.
Yes, that's what I intended to convey -- I set files to finish closing on the layout to which I want them to default when opening -- preferably one in Form View with a narrow base table (or just globals) -- so there is almost no cache to move from the server before it can refresh.
Except you don't need to do all that. You can simply set the layout in File Options.
Sorry, I have to disagree. From my experience that doesn't prevent related files from opening due to related fields on the default layout. FMP establishes a file-open-context before it switches to the on-open layout. The file schema, layouts, fields, scripts, etc. all have to be downloaded in the opening process and at that time context is established based on the current layout. Otherwise it doesn't even know what layout its on let alone what layout to change to. Then FMP switches to the on-open layout. From my experience by then FMP has established the need to open related files based on the fields on the default layout.
I've tried the process of closing on a layout containing fields from a related file and having the file switch layouts on open. I then opened the file on a WAN with a lot of lag and saw it open to the default layout and then switch to the defined layout. It did open the files that had fields on that layout.
Others have also independently verified this behavior. It was discussed in a very heated debate on what to do about it.
I'm sorry you disagree. Perhaps the behavior has changed since the time you tested it. Perhaps you did not actually change the default layout as you thought you had (see my other point). The reality is that File Options-->Switch to layout... overrides what you're calling the "default layout". If that switch is set, no other layout is "loaded", for any definition of "loaded".
Fortunately, there's an easy way to resolve some disagreements...experimentation.
Can we agree that if the default layout (the layout that FileMaker shows upon opening if no File Options are set) is based on a TO from a external data source, then upon opening, the external file should be available in the Window-->Show Window drop down? That is, after all, the whole point of this thread.
You say checking the Switch to... means the related file will still show. I say it won't. I'd wager a box of bon bons on what the result of that experiment in FMPA 12.0v4.
At the risk of chipping in at the end of a very long thread and based on my memory:
I went through this for the same reasons using a splash screen in a multi file solution. I could never totally / always perfect it using the File option to open to the splash screen every time and without "flashing" (particularly on the XP users). However, when I added identical splash screens to all the files AND added the File Option when closing all of the files - peace broke out. I never honestly knew if I found the secret ring or just masked the issue. I stopped looking.
TIP: when I create a new FILE, I create a new blank table and then the first layout (default) is based on this table. No fields (although I may put globals here eventually), and no relationships to this table/layout. Minimal interface, as I'll be switching from here as needed. Therefore the lag noted by Mr Jones does not happen.
-- sent from my iPhone4 --