Are you specfiying a name for the file or just exporting it with the original name? When I do not attempt to change the file name, it exports with the original file name and correct File extension when I test this on my WIndows 7 system.

If I were to use a script that also renamed the file, there'd be a problem as the accessible filepath within the container field does not include the actual file name and thus the script cannot identify the correct extension to use.

I can think of a few possible work arounds in that situation. One would be a script that moves the file from a non-externally stored container field (can be global) to the externally stored container field. The script could extract the file extension from from the first container field and store it in a text field in the same record as the externally stored container field for use when exporting the file.

That's not quite what I suggested. I suggested that if all else fails, there's a way to capture and store the file extension in it's own text field at the time the file is inserted. But for the scenario that you describe, it should not be necessary. See the images in this and the following two posts.

That's the same thing I get as well...And it isn't one click. I'm looking for a one click method.

what you show above is one click to Export the file, then going through the dialog box is another few (or one more if using desktop).

Is there a way to do this with a single click?

I have no need to save the file on the user's desktop or anywhere else...I just want to open it, not save a copy of it. It is data for review, immediately after review the user would then have to find the file and delete it from the desktop/tempfilefolder/whatever.

Note that the first image above also has multiple steps to put the file in in the first place (File, Image, etc.)...WAY more convenient to drag and drop.

The "Insert File" button is the only one I would need, and it gets annoying quickly when the file is on the cloud buried down ~9 layers within sub-sub-sub-subfolders. Drag and drop is quick and easy...That's why it was enabled in FMP12.

What I did was to manually export using export Field Contents but the process should be fully scriptable and then it becomes a 1 click process. I think you missed my suggestion that you drag and drop or Insert the file into a global container field and use a script to move that file into the externally stored container field. The script can be performed by the OnObjectModify trigger, I believe. Your script can then extract filename and file extension from the global container field to store that info in fields associated with the externally stored container field.

The other option is to not specify that the storage be "Secure" and then you can access the filename directly from the externally stored container field.

Once you have filename, or at least the extension accessible, you can export field contents to temporary items and specify that the file be opened automatically on export. By exporting to the temporary file, you don't leave the computer cluttered with piles of exported files as the files in the temporary folder will not be retained.

Now every time someone drags and drops into the container, Table::ContainerPath changes to the new path, and the OnModify trigger sets Table::Filename to the filename you want (including the file extension regardless of how long the extension is...can be 3 4 or 5 characters long these days)

It seems weird to folks, but when the Export Field contents path dialog pops up, dont be afraid to simply type in $Path...

Storing the file to your desktop works fine the first time, but then if you reopen the file you get a "Do you want to overwrite this file" dialog which requires a second click. Storing it to Get(TemporaryPath) shoves the file in your temporary folder which allows the same file to be put there without opening the dialog.

Hope this helps...there haven't been clear step by step instructions on single click opening of external secure containers yet, so I hope this will serve.

Additional Note: If you drop a file into a portal line container...the portal line container may not be ACTIVE, and if it not active the OnModify script will not launch to set your filename. This is solved by adding an initial line in your "open my file" script to perform the "Set the Filename" script.

Honestly, you could just have the opener script do it all and not worry about the OnModify trigger at all.

and without the use of a global field. {All of these were mandatory for me

I don't follow your reasoning on that. The user would not even know an extra field was involved. And I can't imagine how the use of a global field in your solution as a temporary holding location could possibly cause any issues for you other than the added complexity of having to automate the process of moving the files from the global to the secure/external container field.

I am intrigued by your method. On first read, it sounds like a variation of exactly how I would have done this for any container field--not just secure, externally stored ones. My quickie tests, however, suggested that this method would not work because when I checked the data in my test file, I wasn't seeing any file path to the file when secure external storage was specified. I'll now need to revisit that file and see what I missed as this could argue for an update of my little exploration/demo file that I was using to test this.

OK! That was interesting. FileNames ARE accessible from external, secure container fields, but the text that contains that data is organized differently. In that case, the first line of text that can be extracted from the field contains the file name.

I've had a calculation for a while now that extracts filenames from all different possible insertion/storage options directly from teh container field. I've been able to update it to work with external/secure storage container fields: