Double clicking in container fields no longer opens files134 Views, 5 CommentsSummary: Double clicking in container fields no longer opens filesProduct: FileMaker ProVersion: 12Operating system version: Windows 7, Server 2008, OS X LionDescription of the issue: Filemaker 12 does not allow files stored in containers to be opened by double clicking the file.Steps to reproduce the problem:Upgraded databases from V11 to V12 and none of our many (very many) container fields open by double clicking the file stored inside. Also, new databases created using V12 do not support double clicking files stored inside containers.Expected result: I expected files stored inside of container fields to open when double clicking the file. This is how it worked in V11. We expected to have additional functionality when upgrading to V12, not less functionality.Actual result: Files stored in containers no longer open when double clicking the file. Apparently this feature has been removed.Configuration information: Our databases are very dependent on using lots of container fields. We must have the ability to double click a file stored in a container field and open it directly, not exporting to our desktops and opening it from our computers. This takes way too much time and adds too much work for the number of container fields we use. The interactive PDF containers are nice, but we also use pictures, Word, Excel, and many other file types.
FileMaker 12 Managing Container Data
Storing container field data externally
Answer ID: 10244Last Updated: Apr 04, 2012
Interactive content and other enhancements for container fields
Answer ID: 10245Last Updated: Apr 04, 2012
Please note that double clicking in container fields still works, but only with specific insertion method, storage and interface options specified for the container field. This is true for both Filemaker 11 and 12, but in 12 all of the new options also cannot open a file with a double-click.
If you can set up a container field for them to open with a double click--this would be say a container field where insert file with "store a reference" was specified and which has NOT been optimized for interactive content, then they can open, edit and save the file and changes will be retained--as they always have been.
If you find you have to use Export Field Contents to open the file, then you have a problem. It is posible to use a variable to specify the filename and location to which you export the file when you opened it. Then a second script--attached to a "save changes" button on the layout, could use this same variable to re-insert the file from the location to which it was imported. If you get really cute with your interface design, it might even be possible to automate this so that the user never has to remember to click "Save" to save their edits.
PhilModJunk: If you find you have to use Export Field Contents to open the file, then you have a problem
Is it a problem with the setup of the container/field options, or is it a problem that needs a script? I like to double click on an icon to open a .pdf with Adobe Reader, but I am having difficulty geting this to work right; my container fields are in a portal.
The problem that I am referring to is the one you have mentioned in your original post--changes made while the file is opened are saved back to the copy created by the export field contents step and thus are not "saved" with the original copy in the container field.
I like to double click on an icon to open a .pdf with Adobe Reader, but I am having difficulty geting this to work right; my container fields are in a portal.
What storage option did you select for the field? What insertion option did you use? Did you select "store a reference" when inserting the file?
And note that interactive optimization doesn't work for container fields inside a portal row.
I see from your reply that I incorrectly piggy-backed on someone else's post. If I can't get my answer from some of your other discussions about the topic, I'll repost with more details.