A more detailed example of the code that you are using might shed more light on this issue. You also have the option of reporting this as a possible bug over in Report an Issue.
O.K. Thanks Phil,
I will send you the script tomorrow, (it is 24.00 hours here) I have to do some translation to make in readable for you.
To make it readable and more easy, I build a new small example with the “Save as PDF”.
In this example file just push the button “Print preview” and you get a window with the example letter and a second window with a choice “Print” or “Make PDF”.
If you push “Make PDF”, FM will produce a PDF file.
This works all fine, also in the original database.
But, when is make a runtime, no matter if it is a Mac runtime or a windows runtime, the system says; “Save records as PDF is cancelled. You want to continue the script?”.
PS. If you try it on your system, you have to change the file path in the script “Make PDF”, because I used fixed file paths. (But I am sure you are aware of that issue).
This is where the file is located in dropbox: https://www.dropbox.com/s/5f7dwwxohua89ek/SaveAsPDF.fmp12?dl=0
I other situations I have lists instead of a single document. In those situations the user has a choice; "Print", "Make PDF" and "Make Excel".
In those situations the "Make Excel" is working properly in the runtime and "Make PDF" is cancelled in the runtime.
And the "Make Excel" is build the same way with the same variable.
Thanks for your time and reply,
In the Dutch version this is mentioned also, but in a different way, I had to look a couple of times before I saw it. (My mistake that I didn't see the compatibility issues).
Is there a work around? I know I can print the documents and then "Print as PDF". But the problem is that I create my own filename and path, which I use later for automatic mail.
If I can't save as PDF with my own file path and filename it will be more work for the user, but more worse, the chance to make mistakes will be great, and it are all "privacy" matters.
The only work around I know is the one you mentioned and that is printing to PDF. There are several different print driver version that will let you name the PDF. You could also use a plugin, apple script, or vb script to rename the file.
Thanks for your time, help and effort,
I will have to find out what the best way is. But nevertheless the risk of making mistakes by the user with high privacy sensible information is increasing dramatically this way. The way I build it now (with saving PDF files and automatically mail to the appropriate person with the right PDF) almost excludes mistakes because the user has no influence where the PDF is stored an to who the mail is send.
Thanks again for your help.
You may want to check out the MyFmButler plug in as a way to gain scripted control of the printing process used to generate the PDF in your run time.
Runtime only keeps the user from having to purchase Filemaker and doesn't protect your file, security protects your file which is available in both. Filemaker 13 is 299.99 from amazon. You can setup the database where it looks just like a runtime running. If you consider the price of a plugin, price of PDF creator, and the risk of users making mistakes. It 's a no brainer too me. Buy filemaker then you can use save-as-pdf. You can create a icon to open your database, and the user doesn't have to know that filemaker is on their system. The database in the runtime usually just has a different filename extension (doesn't have to be different), but it will open just like any other database, it is only limited by the security just as any other database. There is not much of a reason to use a runtime.
Both thanks for your advise and help,
But a runtime is different. I have full custom menus and security. But if the user has full FM, there is always the option "tools" in the menubar, and users can get access to the "Standard FileMaker Menu" and get access to other options. The second thing is that there is still a bug in the Mac version. Even when everything is set "off", they can get access to the menubar by clicking the right button of the mouse. But you are right in a certain way, the price should not be an issue. (But the Dutch version is more expensive than the English version).
I will also have a look at the MyFmButler and try to figure out what the best way is.
And, it is my own mistake that I missed the compatibility issue that Save As PDF is not supported in the runtime.
Thank you both,
But if the user has full FM, there is always the option "tools" in the menubar, and users can get access to the "Standard FileMaker Menu" and get access to other options.
Only if they have a full access password. Without that, they cannot do this. Not only do you not have to give them that password, you can completely remove all [Full access] passwords from the copy you distribute.
And with a runtime file and the [Full access] password, you can open runtime files with FileMaker Advanced and have that same level of access to the file.
You are right, but I followed your suggestion and use a data separation model. So, the data and software are separated. I wanted to prevent that users have to login twice. So the users only login in the data model, where all security is arranged, and a standard login for all users for the software part. That is why they still have the “tools” option if they use FM. The user still doesn’t have full acces, but they can e.g. switch lay etc. in the software part.
And there is still a bug in the Mac version. I also hide the “tool bar”. If a user clicks the right mouse button, the can open the “tool bar” and do things I don’t want them to do. That is also avoided in the run time.
I had a look at MyFMButler, and it seems to work fine. But, there is one disadvantage, the Mac and Windows version are different versions.
I think I will have to do some more homework and think this over and figure out what the best way is to deal with this issue.
Thanks for your help.
But using the data separation model does not require allowing the user to open the file with a [Full access] pasword!
Both files can be password protected and the user still only gets one password log in. When you open file A with an account name and password and then a data source reference in that file causes file B to open, FileMaker will first attempt to open File B with the same account name and password used to open File A. If such an account exists in file B, the second file opens without the user having to enter an account and password.
You can also set the interface file to automatically open with a limited access account name and password in file options and then the user only gets one password dialog--the dialog to open the data file.