1 of 1 people found this helpful
If the container field is optimized for Interactive Content only the jpg is removed from the O.S. folder-- the pdf stays put.
I've seen a couple of comments stating similar issues, possibly something to do with file being locked as in use by OS. Imagine worth a report, question to the mothership.
if you 'insert picture' or 'insert pdf' you get jpg thumb of it also (unless already a jpg).
If you insert using 'insert file' you do not get the jpg and cannot interact with a pdf even if in an interactive field'. So if you need the jpg and interaction, script insert pdf or insert picture but script removal using a layout that does not incude an interactive version of the field.
I came across this the today at a client. I'd written an 'Insert File' script step with all settings I wanted but when back today I noticed some PDFs weren't interactive.
Turns out one user had been using right click Insert File on container field. And turns out this is the old school 'Insert File' (view file as static icon) but the new 'Insert File' script step (and Drag & Drop) is new FM12 method which sets as interactive by type etc.
Basically its best to use script driven 'Insert File' everywhere and avoid letting user right click field to insert (unless thats what you want).
I've got around balancing interactivity vs not allowing right click in field by
- turning off field entry in inspector on container field in main layout,
- button to 'Add File'
- button to 'View File' which pops viewer layout for interactive view of container (where field access allowed) - still open to right click errors in that view i think but not a big deal for now.
I asked the lead dev about new 'Insert File' script step vs other Insert steps at Devcon. He said can just use Insert File script step for inserting any files, it does all the file type / set interactive if possible stuff for us (drag & drop same behaviour). e.g if PDF file will give a Interactive view if set as interactive on layout. Other Insert steps mainly for backward compatibility as I understand.
If you leave a file which is no longer the target of a container field undeleted in the O.S. Folder , and insert it again, FMS adds _1 to the file name. I will do this even if you first delete the original directly using Finder on the server . (The change of name would be an issue if you plan to directly access the file.) However if you empty the container with no interactive field instance present the file name is not changed.
This one is expected behaviour, the rule is if you wanna do anything with that file (other than copying it off somewhere) you need to manage it through the filemaker UI. Filemaker see's that external file as part of the database just as it did when it was an embedded container.
Does my finding this stuff interesting mean I am a total dweeb?
I may have just out dweebed you.
Your point on the new options of the Insert File script step is helpful. I had overlooked trying them -- if you select 'Display/Content of File' in Dialog Options when inserting this command into a script or attaching it to a button, you will get interactivity if a field instance on a layout is set to provide that.