I'm sure you meant 10.10.3, not 10.0.3? 10.10.3 is a beta release, not even available for public download yet.
Is this happening with the same PDF, on the same machine?
Or is it one PDF is different than another?
Or is it that one machine is different than another?
How are the PDFs stored? As a reference? Embedded? Server managed storage?
PDF previewing relies on the user's system default PDF viewer, and valid access to where the PDF file is stored.
Thanks for your reply Mike
10.10.3 you are correct of course, I am placing the pdf in a global container field via script step for checking before emailing it.
only meant to there until the email has been sent, the real file is stored by reference to an external Folder on the local machine.
I thought it could be how its named… tried different ways it just does not work consistently.
maybe its related to Yosemite PDF handing?
I can understand if it has issues online however expecting it to work on my MacBook Pro 13 it has 16Gig of Ram and a rather large SSD with room to spare.
Thursday morning… have attached a screen-shoot, when it works I would bet a small preview of the pdf I have a preview button to bring it up large just below the field.
MailAttachements.jpg 114.7 K
Could it be related to the number of pages in the PDF? In Mail, a single page PDF shows the actual content, but if there is more than one page you get a generic PDF icon.
You can optimise the displayed field for Images (jpeg etc) or Interactive (PDF etc), and you can Insert Picture, Insert PDF, or Insert File. These combinations display the contents in different ways, some experimentation may be required.
From your client context (the user), do they have access to the PDF where it is stored as a reference?
They may not be able to copy it into the container field used for previewing, so it’s only copying the path.
Storing PDFs as a reference requires the user context to have access to the location where the PDFs are referenced, otherwise stuff doesn’t work.
I've run into this problem with a client of mine. I've found that using a script step of Insert File seems to cause the PDFs not to be interactive. The only way I found that works is to either drag the PDF into the container field or use the insert PDF menu option or right click option.
Thank you all for your thoughts
I am using Insert File script step and it works some times and not other time there must be a reason for it…
I'll do more testing…
Here is an interesting test result copy pasting the insert file script step from somewhere else in the script seems to fix it.
I find this at various times that removing script lines altogether and putting them back in seems to somehow correct issues.
Maybe it means the script line is somehow corrupted?
So No "Insert File Script Step definitely works" seems to be more of a script editor issue…
having said that I am using a few plug-ins to improve how the script editor works… suppose that comes at a reliability cost.
can't always have it all I suppose, thank you all
We have exactly the same problem and have filed multiple reports back to FM & apple.
Sometimes it is related to how much PDF work you do, opening, attaching, viewing.
We can reliably crash the Filemaker instance just by manipulating the way we view PDF's
We also see 'window' corruption, where the PDF will not view correctly via the mouse scroll button,
parts of the document move whilst others are stationary.
This is single page documents, with the latest osx 13.5 server & clients (10.10.X)
The whole situation is just shabby programming and handling of the PDF formats, some of these bugs were supposed to have been fixed back in FM 11
maybe it helps to highlight the issues…
as its otherwise such a useful feature and yes OS X APIs should be doing all the heavy lifting.
so maybe its more to do with filmmakers code not fully modernised and yes it needs to be cross-platform.
One of the places I had the problem in turned out to have an extra script-line replacing the perfectly good container copy…
so pays to have shorter scripts and always step past all lines in the de-bugger!
You mean like the 20 or so reports we filed to Apple and the copies of the error we emailed to FM support?
Considering we fork out >30k in license fees a year for 'support' , it is laughable.....
That we Don't have:
1. PDF's that work reliably.
2. A decent developers work bench with GIT/CVS tracking.
3. A CENTRALIZED way to maintain all the code, with out all the 'silly little' hidden & buried sub-command statements
4. A way to be able to ACTUALLY copy & paste code correctly and store it outside of FM
It is as if the whole system was developed by sales people and management consults rather than programmers.
Even foxpro 3.x was better.
I would not be so heavy about it as there's just so many options and variables that can go wrong with a rather complex feature and quite often if you go back into it you may find it can be user scripting errors.