1 of 1 people found this helpful
Each Runtime APP has a "main file" designated to open with the Application itself. That file will be opened by the App every time the App opens, even it is forced open by opening a different file in the runtime solution. So the "main file" selected when the runtime was being generated will be foremost everytime the runtime is opened, no matter which file caused it to open. If it was not the "main file" which was opened manually, or the App itself which was launched, the file opened manually will be lurking open in the background somewhere.
It can be reached via the Window menu, if that menu has not been disabled. Or you will need to use some some on-Open script to provide choices for the users if you want them to navigate to other files.
The only thing you are doing wrong is not anticipating that this is how runtimes behave.
Many thanks for your prompt reply which (unfortunately) confirmed what I had suspected from trawling the FileMaker literature.
I shall have to give some thought to work-arounds but I expect that these may end-up being less than elegant (despite the essentially simple nature of the objective).
One idea to consider: only include the data file that holds the sample data, but add a script that deletes all of the data. Then, when the user is ready to move to the empty file, he/she just runs the "Delete Sample Data" script. I've done this before.
Another technique (a bit more involved):
- Create the runtime with the sample data file.
- Move the newly-created data file (with the .USR extension or whatever else you've designated) out of the Runtime folder.
- Delete all of the sample data from the FileMaker source file.
- Create the runtime again with the exact same settings (this time with the empty data file).
- Rename the newly-created data file (perhaps append "_empty" to the file name).
- Move the sample data runtime file back into the runtime folder.
At this point, you have a runtime with the sample data. When the user is ready to move to the empty file, have him/her quit the runtime, delete the data file, remove the "_empty" part from the other data file's name, and re-launch the runtime.
Rob's technique can also be used to let a user maintain multiple data files, if their use of the solution would benefit from swapping files.
The biggest drawback to introducing this technique to your users is that many runtime users lack the basic understandings of computer systems to make these file file-swaps without making mistakes, and then you get to do some really fun tech support.
I've been taking the second approach so far but it does rely on the user not being too dim (which experience shows to be a perhaps over-optimistic assumption).
The first approach would be my preferred one (especially given that the data file already includes various data purging scripts). I shall give this some thought over the weekend.
Absolutely. I'm always amazed at the number of users who don't even make the effort to understand the folder hierarchy on their computers and so just leave all their files on the desktop or in the default Documents folder! Unbelievable.