By "designed to accept a PDF" do you mean the the container field has been "optimized for interactive content" on your layout?
If you create a brand new file with just one such container field inside a tab control, do you get the same crash with that test file that you do with the original file?
Thank you for the post.
I am not able to replicate a crash using a PDF in an interactive container field. My tests were performed on a workstation Mac OS X 10.9 iMac with FileMaker Pro 12.0v5.
Some additional questions to further narrow this down:
1. Does a new database file using an Interactive Container field behave the same?
2. What is the default PDF viewer/reader/writer on this computer?
Note: By default Mac OS X includes the Preview.app but a user can change to a third party PDF application such as Adobe Reader or Adobe Acrobat.
3. Does this occur when using the Preview.app as the default reader?
Please note: If you double-click to open a PDF and an Adobe application launches, then the default is not Preview.app.
FileMaker Pro 12.0v5 uses the operating system's default PDF viewer/reader/writer. If the issue appears to only occur when using Adobe's PDF software, contact Adobe for further troubleshooting.
Because my english is poor, what first surprised me is the term "tabbed container fields", and i was wondering if Shumit Basu talked about repeating container field.
Then, i did some tests :
- Defined a new container field with three repetitions.
- Defined this field on a new layout as a unique object showing the three repetitions at a time.
- Returned back in Browse Mode
- Seen the three part of the field, but coulnd't insert a PDF. Oh, yes : forgot to define for interactive...
- Returned on Layout Mode and optimized the field accordingly.
- Then, in Browse Mode, my field was merged in one part, strange...
- Inserted a PDF anyways and it worked.
- Curious to know in what repetition my file were inserted, i reverted back the object to static content. OK : The PDF was inserted on third.
- One more time, reverting the optimization to interactive content, to browse finally my PDF, quit Layout Mode...
CRASH -- FileMaker Pro ended unexpectedly.
I was on OS X 10.9 but i am not sure it would be different on 10.8, because the merge behavior is surely not OS-depending.
Moreover, all this was pure speculation about the term "tabbed" that i may misunderstood. But If i am on the right track, tell me and i can do further tests...
And i would really appreciate some clarifications about this merge behavior i experienced...
Thank you for the reply.
Besides the application crash, does the article above describe the behavior you're experiencing?
I tested by following your steps above, but I was not able to replicate a crash. Were your tests performed with the Preview.app as the default PDF viewer/reader/writer?
Workaround: Set each repetition to be its own layout object (field). See screenshot below.
Thank you for the rapid reply.
And also Yes, my tests were performed with Maverick, where i always defined Apple Preview as the default reader.
Were your proper tests Maverick based on ? If so, maybe you can try to repeat step 8. and 9. many times to attempt a crash.
Thank you for the reply.
I tested using a workstation Mac OS X 10.9 iMac with FileMaker Pro 12.0v5 (Advanced) and repeated steps 8 and 9 more than 20 times without a crash.
Preview.app may be set to be the default reader, but are any versions of Adobe (Reader/Acrobat) installed?
During my testing, I discovered that even with Preview.app set as the default "Open with:" for PDFs, if any version of Adobe is installed, then Adobe behaves likes FileMaker's default reader.
Do you have either of the Adobe browser plugins for Safari installed: AdobePDFViewerNPAPI.plugin & AdobePDFViewer.plugin?
After removing both of these plugins from /Library/Internet Plugin-Ins and relaunching FileMaker Pro 12.0v5, then the Preview.app properly loaded the interactive container PDFs.
Observe the menu bar options provided in the container field to determine whether Preview or Adobe is loading the PDFs. From the screenshot below verify whether the interactive container(s) within your database file load showing option #1, #2, or #3?
TSFalcon :Thank you so much for theses precious informations. I can now understand why, and thus, predict when, FileMaker Pro will use Apple Preview Or Adobe Reader components, to display content within his interactive containers, and that is really cool !!!
All :During my first tests, the crashes were very unpredictable. Sounded like RAM management problems. But after hours of tests, i was able to reproduce surely the crashes with 5/5 success on the configuration i talked about on my previous post. For that, I used an OnPreviousWindowOpen triggered script, that do some repetitive PDF insertions.I tested WITH Adobe 11.0.4 components and WITHOUT them.I repeated the same tests on another machine that was on Mac OS X 10.8. Then i installed Maverick on it. And i repeated again the same tests.Then, i modified my database, and tested again with non repeating container fields too.And all these tests confirmed following :The culprit were the combination between Adobe 11.0.4 components AND OS X 10.9.This configuration always failed.The presence of repeating fields on the database were not relevant.Apple Preview AND OS X 10.9 always worked.Adobe 11.0.4 components AND OS X 10.8 always worked.Edit : all my test were performed with FileMaker Pro 12.0v5.Bye, Fred
Can you confirm Fred's findings (which now have helped in another thread as well as here)?
If so it appears that we can put our third "Mavericks Only" bug into the Known Bugs List.
Thank you for the replies.
I can confirm my testing produced identical results to Fred's testing. Product Development has also confirmed.
An entry in the Known Bugs List has been linked to this Issue Report. Any question/comments/suggested corrections about that entry should be posted here or in a new thread. Please do not post such comments in the bugs list thread.
10.9 & Interactive Container Fields: those fit my circumstance. The bug discussed here fits with the exception that I did not recognize this issue initially. I.e., I created a database with interactive container fields, and entered about 100 records, all with Mavericks and no issues. I recently updated my FM installation with 12.0v5, and I THINK that this is when the issue arose.
Reading the thread above, I change the PDF file association to Preview, but experience the same crash issue - after opening the file, it crashes upon the first interaction with the file. Always.
Thank you for the reply.
One of the discoveries made in this thread is that even if Preview.app is set to the default PDF association, and the Internet Plug-Ins "AdobePDFViewerNPAPI.plugin" or "AdobePDFViewer.plugin" are installed, then Adobe is still loading the Interactive Container content.
I am reposting the screenshot from my previous post for clarification. From the screenshot below, please verify whether the interactive container(s) within your database file load showing option #1, #2, or #3?
I was having these crashes in my main file, so I created a very simple file, just to see if it was something I was doing wrong. The error is very simple to reproduce, at least on my equipment (Intel Power Mac Pro, OS 10.9, FMP Advanced 12.0v5, Adobe Reader 10.1.8.
Created a new file, created one Layout which includes only a container object, set to active. Start adding records and transferring PDF's to the container. May not crash on the first, or second, but sooner or later it will crash. If you are successful in loading some PDF's, and then try to move between records, it will crash. Doesn't seem to matter whether the PDF's are stored internally or externally, but if externally, the crash appears to occur AFTER the records have been stored (both the PDF and an accompanying JPG.
I'm no expert at diagnosing these problems, but appears to me to be when the JPG is being displayed, and appears to be that the target memory location may already be occupied, and OS10.9 objects to that.
Could be an interaction problem between FMP and Adobe, but I would hope that FM would be so kind to work it out with them. This bug is a stopper for our project.
I will attempt to upload the front end of an error report along with this post.