When do startup scripts run? When does it open?

[kennedy]

When precisely do startup scripts run?

They run if you explicitly open the file from the File menu.

But what if the file is opened by another file?

What if a file does "Open Hidden" on another file?

What if a file just calls a script in another file?

What if a file just uses a relatonship in another file?

What if a file just looks at the definitions in another file?

In each of those cases, does the startup script run?

I thought a file with (parens) in the Window menu was opened, but hidden.

But I am noticing that many times such files have NOT had startup script run.

For example, *all* my files have Doc prefs set to run the script "Startup" at startup.

And *all* my files Startup scripts go to the proper layout, turn off status area and such, and then zoom the window. If I open one of my files explicity, usually that will open several others that appear in (parens) in the Window menu. If I select one of those, it will often be in the state I left it last time I quit, rather than in the state that should have been set by the startup script. Thus, it appears that startup script is NOT being run!

Bonus Question: If you call "Open" on a file that is already open, does it do nothing? Would it ever re-run the startup script? What if a file is in the "opened in parens without running startup script" state... will calling "Open" cause the startup script to run?

Thanks for any enlightenment!

[kennedy]

Assuming the answers to the previous questions are "I should explicitly open unhidden every single file I have at startup", here's my follow-up questions:

Can I have my Startup script in my "Globals" file open every single file, and have the Startup script for each of my other files open the Globals file? Or will that setup weird circularities?

Assuming that's okay, should I open "Globals" first, then cleanup my window, set vars, etc. Or should each file do all its own stuff, and then end with the call to Open "Globals"?

Does it matter which order I open the files in "Globals"? And if so, how does that affect the previous question? I guess the key issue is whether if you open them in the wrong order, will some of the files get opened without startup script because they were opened via relationship or script before being opened explicitly?? Or will the explicit open run the startup script even if the file is already open?? (Returning us, of course, back to all those more basic questions I asked in the previous note. Sigh.)

Thanks. (P.S. Neither the FMP manuals nor the Coulombre/Price book answer these questions adequately... the latter partially answers a couple of them.)

[LiveOak]

The circular reference can cause a delay in opening the files. Open "Globals" first. The order matters. A file can be opened by it's use in a relationship by another file. This will avoid the exection of the startup script. The best idea is to run the startup scripts explicitly from the globals file (Open(), Perform Script(External)).

-bd

[kennedy]

Yes, I have it set up so Globals opens everything. And I'll figure out how to do it so they don't open via relationship or script. But what if someone explicitly opens one of the other files?

I figured I'd just have every other file open Globals, assuming that if Globals startup was already running, the "Open ["Globals.fp5"]" would do nothing. Is that so, or will it cause problems? Further, should it do that open first thing or last thing?

Or should I just insist that people open it "properly"? (Actually, that's practical... this will be deployed on FMServer and I'll be making everyone a Open script for their desktop... HOWEVER, I prefer fail-safe for the person who finds Open Hosts... and for posting here as a template.)

So, what's the best way? Thanks.

[BobWeaver]

On the application I'm doing now, I prevent users from opening anything except the main file first by putting the following steps in each files' start script.

Allow User Abort [off]

Set Error Capture [on]

# Check if the main file is already open

If [PatternCount(DatabaseNames,"MyMainFile")]

# Main file is open so...

# Do the rest of the startup stuff here

Else

#Main file is not open, so exit

Show Message ["Please run this application by opening MyMainFile.";Button1:"OK"]

Quit Application

End If

---

Then the main file's startup script opens all other files.

[kennedy]

Ahh, cool... I hadn't found the DatabaseNames function before.

That'll work great. Thanks!

[Vaughan]

I'd use Close instead of Quit -- the user might have some other FMP databases open and it'd be nasty to quit them right out for opening the wrong file.

[BobWeaver]

I tend to get nasty if users are screwing around doing things the wrong way. In this application, they shouldn't be using Filemaker for anything except the files in this solution. But, in different applications, yes, Close might be better.

[mgeorge]

I had the same problem until I realised the best method for me was to have all the secondary files run a startup script:

Toggle Window[Hide]

Open[Open Hidden, "centraldb.fp5 (gov.ns.ca)"]

close[]

Once centraldb.fp5 opened it would execute a startup script that took care of setting years, window cleanup, and then user routing. The user routing routine would then selectively open secondary databases depending on the user log in and execute the setup subscripts for those individual databases.

The short answer is basically all roads lead to Rome and from there the world.

Mike

[mgeorge]

I used to get upset with users when they constantly did things 'wrong'. It was only 'wrong' because I hadn't thought that anybody would do that. Therefore I was 'wrong' in not anticipating the users interaction with the database. Then I realised that the only way I would keep my sanity is if I controlled every single step they took. I mean validation on almost every field they could possibly enter data in, creating separate 'browse', 'edit' and 'find/search' layouts, keep track of where they are in the databases at all times, trap all errors, singular entry/rentry points. Fully half of the calculation and scripting in this one 5 year project I'm working on is dedicated to interception and guiding of the user.

I've had to keep reevaluating the lowest common denominator of basic user skills, until I realised what it is called. Breathing.

Sorry to sound like a rant but it has been a long day.

Mike

[Vaughan]

The only peroblem that I have found with Hide is that id doesn't really work on Windows... it un-maximises all the others. I find it easiest to keep every one maximised.

[BobWeaver]

I need to backpedal a bit here. I gave an oversimplified answer about forcing filemaker to quit. I have an opener file on every client computer and the main files hosted by Fm Server. If a situation occurs where a file is opened in the wrong order, it's because the user didn't use the opener file and fearing that someone might have turned on filesharing on the server allowing direct access to the files, I figured the most secure method to protect things is to quit Filemaker on the client machine.

[kennedy]

I had the same problem until I realised the best method for me was to have all the secondary files run a startup script:

Toggle Window[Hide]

Open[Open Hidden, "centraldb.fp5 (gov.ns.ca)"]

close[]

So, the call to open the secondary file results in a call to open centraldb;

that call results in calls to open all the files, including the secondary one that

started it all (which does nothing, since its already in the process of opening);

after centraldb has finished all its startup script and opened everything, control returns to this secondary file's startup script, and...

it closes the secondary file that was originally opened.

Isn't that quite undesirable, since that's the most likely thing the user wanted to see... and now its the ONLY file that's NOT open??

[mgeorge]

I'm sorry, I think I left out an important piece. I don't open the secondary files from the central database using an 'open[]' command. I force them open by executing a subscript from each secondary file. When it is done this way the startup script for each file is not run.

Secondary files startup script:

Toggle Window[Hide]

Open[Open Hidden, "centraldb.fp5 (gov.ns.ca)"]

close[]

Primary file startup script:

Perform Script [sub-scripts, External: "Acc.fp5 (gov.ns.ca)"]

Perform Script [sub-scripts, External: "Att.fp5 (gov.ns.ca)"]

Perform Script [sub-scripts, External: "Out.fp5 (gov.ns.ca)"]

Perform Script [sub-scripts, External: "Fes.fp5 (gov.ns.ca)"]

The external script called in each secondary file is a 'Setup - Window' script which is basically the initialisation and window handling script for each file.

It works and it forces the users back to the central database with only a few extra screen redraws.

Mike

[kennedy]

I'm sorry, I think I left out an important piece.

Ahh, yes, that makes sense. Thanks.

[mgeorge]

TechInfo article no. 104081 at www.filemaker.com states the following:

"When a file opens due to a relationship (i.e. a related field appears on the current layout) ,an external script, or a value list that uses a secondary file, the startup script for the related file will not run. To compensate you will need to anticipate when files will need to be opened and open them with the Open script command."

Mike

[habitude]

From my limited FM experience, there is a lot more to consider when it comes to FM solutions.

A fairly large 21 file solution currently in use where I work was built years ago, and has literally hundreds of scripts and layouts, one each for browse, find, view.

The solution is locked down pretty good, but with all the excess layouts, graphics and junk, the program tends to run very slow in a multi-user environment.

Dont forget to take in account which user access, levels of access, where they can travel, etc... Password validation ...

I learned the hard way when I built my first solution... the entire program practically imploded on itself! -)