Sounds like an operating system issue. This feature of Export Field Contents is supposed to use the File Type and your OS systems specified "default application" for that file type to determine which application to use to open the file. So it is an OS setting that determines what application is used to open the exported file.
That makes sense. But what's weird is that sometimes it chooses to open a Word document in Word and sometimes it chooses to open it in TextEdit. I can't find a pattern for when it chooses to do either. It you look at the field contents before exporting, it clearly shows a Word icon, but chooses to open it locked in TextEdit anyway. Also, it is happening with multiple users, not just one machine. Is there anything I can do to test it?
Not all word documents have the same file extension. Is it possible that the documents in question have a file extension in common?
We only have .doc and .docx and it doesn't make a difference which one it is. I thought of that as well and tested it. What's strange is that it's been working fine for years and I haven't changed anything.... ? I'm confounded.
You haven't changed anything deliberately but you OS could easily have been updated any number of times and the software installed on your system may be different or updated.
Let's try a test.
Use export field contents to export one of these problem files to the desktop without specifying the option to open the file automatically. Close or minimize windows until you can find the file on your desktop and open it by directly double clicking the file on your desktop.
What happens next?
What should happen is that you see this file open with the same application opening it as you have happen with export field contents and the automatic open option.
I'm curious to hear if you get any messages or error dialogs popping up and if you really do see the file open in textEdit.
You are right. The OS has recently been updated.
I exported the field contents to the desktop without automatically opening the file. When I double click the file on the desktop, it opens in Word like it is suppose to. So I tried exporting the field contents and automatically opening it without using my script and it also works fine. There must be something broken in the script then. In my script the file opens to a variable: $$DownloadPath = Let ( [
MAC = "filemac:" & Get ( TemporaryPath ) ;
PC = "filewin:" & Get ( TemporaryPath )
Case(Abs(Get ( SystemPlatform )) = 1; MAC; Abs(Get ( SystemPlatform ))= 2 ;
PC ) & Get ( ScriptParameter ) )
I would prefer the user be able to open the file without having to save it to their computer unless they want to. Is there a better way to do this? Thanks!!!
You can certainly simplify this by using file: in all cases instead of filemac: and filewin:. Depending on the version of FileMaker that you are using, you may be able to just use Get ( TemporaryPath ).
Any time I try to use Get ( TemporaryPath ) or "file:" & Get ( TemporaryPath ), I get the following error:
""Get ( TemporaryPath )" could not be created on this disk. Use a different name, make more room on the disk, unlock it or use a different disk."
I use FileMaker Pro 13.
I found a fix. Because my variable is "file:" & Get ( TemporaryPath ) & Get ( ScriptParameter ), it doesn't assign a suffix to the file type. Normally it can tell what type of file it is and open it in the proper program. However, there are a few that do not open in the correct program. I simply changed the script parameter to include the file type (i.e. .doc) and it opens correctly in Word.
I suspect that you don't need "file:" at all. I left it out in FileMaker 11 one time for this type of file creation action and it worked fine. Then my client tried to use the file on his FileMaker 10 system and it didn't work until I put back the "file:" tag.
But you can get the full file name including the file extension from your container field.
I have a file that you can download that includes a calculation field that can extract the filename from a container field regardless of insertion method and storage option specified. (With the exception of inserted objects in FileMaker 11/windows which never inserts a file name in the first place).
See this thread for a download link: Exploring the use of a $Path Variable in Scripts
You are right. I don't need the "file:" part at all. :) It is apparent that my knowledge of this type of scripting is limited. Thank you for the link that you included. I am going to dig into that file. I know it will be extremely helpful to me!