Bind all the template files during the runtime creation.
Use a script with Open File steps to open selected "template" files. Use a script with Save a copy as to save a copy of the file with a user specified name for the file. Close the template file immediately if you don't want to allow the user to make changes in the original copy.
Thanks for the reply. I can see that I shall have to increase the complexity of my solution in order to achieve my objective.
Just to be clear, are you saying that if a user opens the template (primary) file and then specifies a name via Save A Copy then the newly created runtime data file should be able to be opened from the desktop without the need for the primary file?
I think that it will. I suggest testing this to be sure. This works for a single filemaker runtime. With multiple runtimes, you need to be sure to specify unique file extensions or attempting to open the file could result in a different copy of the runtime application attempting to open the file and stopping with an error message if the "bindkey" doesn't match.
Safest approach would be to add that Primary file you don't want. There's no need to hide it, however. Opening it can present the user with a menu of choices, open a template, open file ABC that was created yesterday, etc. FilePaths can be stored in different records of the primary file to function as links to the other files.
No luck with that approach but I shall start to play around with the startup script. Unfortunately this includes my own Registration (copy protection) process which complicates life somewhat!
There is always a solution to these problems but in the end it may just be easier (although rather clunky) to ask the user to mess around changing file names when required... (ugh...).
No luck with that approach
Just for my own ongoing education, exactly how did that fail?
1. Created new runtime (AppX) & data file (Data1) (with Save A Copy As in the File menu).
2. Opened Data1 by opening AppX.
3. Selected Save A Copy As, name Data2, location same folder as Data1 & AppX.
4. Closed Data1.
5. Opened Data2 from the desktop.
6. AppX attempts to open Data1.
7. "Open Data1" window appears. If I enter Account Name & Password then select OK, Data1 opens, not Data2. If I select Cancel then "Open Data2" window appears.
8. If I enter Account Name & Password then select OK, Data2 opens and then closes itself, displaying the default Made with Filemaker exit window rather than the custom one set during runtime creation (which does appear on Data1 close).
From the above I've drawn the conclusion that the original primary file (Data1) must be open for the copy (Data2) to work.
Clearly I need to give this some more thought...
Hmmm that argues for that primary file with records that link to the user created files.... Not your first choice, but workable I think...
On this occasion I'm tempted (at least initially) to try to keep to a single file with a sample data purge script as suggested by RobWestergaard on the FM Technical Network.
Whilst this wouldn't suit everyone in my case I might be able to make it work. I'm keen to avoid increasing the complexity of what is already a pretty tricky (albeit hidden from the user) startup process.
Anyway, thanks for your suggestions which are much appreciated.