Launcher Files are pretty common in the FileMaker world. They solve two common problems.

1. Desktop Shortcuts - Typical users do not want to have to go through the hassle of launching FileMaker, opening remote, finding the sever, finding the file they want to open, and then opening it. Yes this is a bit easier with FM9. But still users want one thing to click. They click the Launcher File, and it does the work of finding the right file on the right server to open.

2. Running Scheduled Scripts - Both Mac and Windows have built-in scheduling tools. The Mac has iCal, and Windows has the Task Scheduler. It is relatively simple to use these tools to schedule a file to be opened whenever you want. Yes, there are event plug-ins that can do this, but I find that using the built-in OS level scheduling tools is more robust. They always work, whereas the FileMaker, plug-in based methods only work if FileMaker is running. Yes, again, this is easier with FM 9 Server scripts, but they are somewhat limited. So we still need this method.

The basic concept is simple. You set up your Launcher File to run a script when it opens and have that script open your target file and run your target script. But in practice, it is a little bit more complicated to make it work all of the time. Here is how I do it.

First here is the File Options dialog where you can set scripts to run On Open and On Close.

.

I set a script called "On Open" to run when the file opens. I also set a script called "On Close" to run when the file closes. It is actually the "On Close" Script that kicks off the process. The "On Open" script just closes the file. Let me explain why I do it that way.

If we used the more obvious method of just using the "On Open" script to do the work and then close the file, there is a chance that the Launcher File will get left open. For example, if your target file runs a script that includes a Halt, your "On Open" script would never get a chance to close the file, and the Launcher File will get left open. Not only does this confuse users, it will stop the Launcher File from working the next time a user clicks on it. Since it is already opened, it will not run it's On Open script again. So we need to ensure that the Launcher File is always closed at the end of its job.

One way to do that is to use the "On Close" script to open the target files or run the target scripts. Then the "On Open" script's only job is to close the file. That trigger's the "On Close" script to run, and, since the file is in the process of closing, it can't be stopped from closing by a Halt script step or anything else.

So I use the "On Open" Script to close the file, that calls the "On Close" script, which does the work. Here are the scripts in the order they get fired.

Notice that I use an IF script step to keep the Launcher File from doing its thing when I log in with [Full Access]. This makes it possible for me to administer the file and make changes if necessary, without triggering the target file to open or the target scripts to run.

Also notice that I use a third script "On Launch" to actually do the work. This is not necessary, but it makes it easier to maintain. I never worry about the On Close and On Open scripts again. I just adjust On Launch as necessary.

If you are using this to run a script in a target file with a certain user name and password you can set the Launcher file to open automatically with the correct account using the File Options dialog above. This should only be used for automated processes and script triggers. You should never give users a Launcher File with embedded passwords. It is bad practice.

I have included My version of the Launcher File below. The admin account is "LauncherAdmin" with no password.

Have fun!