if i understand correctly...
Fields contain <HTML>strings</html> which are then compiled together via calculations (or w/e method). The final output is then intended to be saved as an .html file then recaptured and placed back into its respective record container?
I imagine you would need to script an export field contents to an appropriate format such as . and then recapture that export file, then insert back into container field.
this is a very crude script idea to point in right direction . Hard to give an accurate response for your specific solution. for instance is it going into a different table/ related record, dynamic file names or paths, etc...The script would have to be added by the host and you call the script.
Thanks for your reply. You do understand the issue, perfectly. Your script would work great for the FileMaker client. Unfortunately, the Export Field Contents does not work for WebDirect. It appears to export to a file in the default download location for the web browser on the client (not the server).
"FileMaker WebDirect does not support the Specify output file option. FileMaker WebDirect exports field contents to the web browser’s default download location."
This is the issue I've been trying to work around for months. It would work great if I could just export to a temp file on the server then insert it back into the container, but.....
do you have access to the host file? I am just thinking out loud to stimulate thought and hopefully a solution.
Would it be possible to have the admin set global var at the start of a webdirect session using get(systemversion) to identify browser type. (i believe within a browser it will identify which type) Then once browser is identified you can select the default location using case() or if() and set $FilePath for when you insert file into the container
$$browser = IE; Set $Filepath = " IE default path"
$$browser = Chrome; set $Filepath = " chromes default"
FM16 has new function TextEncode(), so you can "Set Field" instead of "Insert File"
But accessing external open container from IIS may not be preferred. (I saw the usage in FMS12 but deprecated on newer version...)
Wow! Thanks so much. That looks like exactly what I've been looking for. I'll try it out. Is there a way to name the HTML file in the container other than the Export FIeld Contents step?
BTW, the whole point of this exercise is to be able to provide external access to html files (Google Chart code) for public viewing without loading the FileMaker server. That part works great. I just set a virtual directory in IIS to the open storage directory for the html files. Is there a better way to do this?
1 of 1 people found this helpful
To set filename,
Base64Decode ( Base64Encode ( <<container or use direct TextEncode() here>> ; "filename.ext" ) )
Thanks again for your help. This works perfectly to create an HTML file (with a selected name) from a text field.
Set Field [Charts::Chart_HTML_Container; Base64Decode ( Base64Encode ( TextEncode (Charts::Chart_HTML_Text; "utf-8"; 1)) ; "TestGoogleChart.html" )]
Now, the only problem left to solve is FileMaker creating a new version of the file in the external storage. If the filename set is "TestGoogleChart.html" and I Set Field [Charts::Chart_HTML_Container;] to erase the file then rerun the script step, the actual filename is sometimes set to "TestGoogleChart_1.html", "TestGoogleChart_2.html", etc. When I run the script step GetContainerAttribute ( Charts::Chart_HTML_Container; "filename"), it always returns "TestGoogleChart.html" regardless if a version suffix is added. Ideally, I'd like to be able to force it to always overwrite with "TestGoogleChart.html" or, alternatively, be able to get the actual filename created. Somewhere FileMaker knows the filename associated with the container.
1 of 1 people found this helpful
into a MyChart.html file in a container field using open storage. With this, I can use IIS to access the MyChart.html file from outside of FileMaker.
A warning: Remote Container data files are not meant to be visible or touched from outside FM; they should be treated like the live FM files that they are.
In order to do what you want you would need to give access to other processes to access those protected folders. That breaks all best practices and is potentially dangerous because of it.
It is using a feature outside of its intended scope and I would not build a production system based on that.
So....I took your advice to heart and now, am still trying to figure out how to get a file accessible by IIS. My thought was to create a PSOS script to export the container file to a separate directory on the server. Then I found out that "Export Field Contents" is not supported on either the server or WebDirect. Is anyone aware of another, supported, method to export the .html file in the container to a directory on the server?