Welcome to FileMaker!
In the first place, you need to know you can't display word files stored in container fields, although it can store them. Look up "Using data in container fields" in the FM Help menu.
Secondly, if you store your documents as either PDFs or images you would be able to create a layout with a container field set to optimise for interactive content (find this under Data Formatting in the Inspector).
Third, the best way to manage your containers is using FM's own external storage.
The attached file should help get your started.
ContainerDEMO.fmp12.zip 635.1 K
Thank you for the welcome and the helpful answer. After playing around with the Demo you attached and looking further into what I was hoping to accomplish, I think I finally understand what is causing my confusion.
As I mentioned, I wanted to create a container to store files. I wanted Filemaker to handle the stored files externally. I also wanted co-workers to be able to access those files for themselves, not neccessarily to manipulate, but to read or simply look at.
So I created a Container field and chose to allow Filemaker to store the file externally.
Now, and this is where I was confused, when someone puts a file in the container, the next person who wants to see it can not simply double-click to open it to view it. It must be Exported, saved somewhere else and then opened.
The reason for this was explained in another post, which I would like to give credit to, and which does make sense from the point of view of the data integrity.
From what I understood, the take-home message is that once you drag and drop your file into the container, Filemaker stores the file for you in its folder. You (or the database) doesn't want other people changing this stored data, so you must first make a copy of the stored file somewhere else and then choose to have the OS open it.
Thus, you can not simply double-click to open a file that you drap and drop into the container field. At least if it is not one of the supported file types.
I think this explanaition doesn't apply if you choose to insert a file into the container by right clicking on the container or choosing insert from the fil menu. But I'm not positive.
Does this sound correct?
Re: "the next person who wants to see it can not simply double-click to open it to view it. It must be Exported, saved somewhere else and then opened"
–Yes and no. If the file is one that FM can display there is no need to open it in its native program in order to read it; you can read it inside FM if the container field is large enough. That is the point of the container viewer layout I included in the demo file. This be made elastic using the autosizing options—just anchor the container field to right and bottom as well as the default top and left, and it will enlarge or shrink according to the size of the window (you set this in the Inspector—see screenshot below).
If the file is a format that FM can't display (eg. wordxyz.doc) then, yes, you would have to export it back to Word in order to open it. A better solution, however, would be to convert it to a pdf and store it that way.
I think it is a really good idea to design your db to facilitate (1) inserting files you want to store; (2) read them directly in the db; and (3) export the contents if necessary. The keys are the user interface, and the scripts you create.
Re: "You (or the database) doesn't want other people changing this stored data"
–Sort of. A really important point is, if you choose to manage your documents via FM, don't ever go messing with them directly or let anyone else do so.
If you have to later change a stored file you can always export it and open it with it's native program (if it was originallly a Word file which you saved as a pdf you can then convert it back into a .doc format, make your changes, re-save it as a pdf and then store the new version in the container). The thing to remember is that a single container field can only hold a single file; if you drag (or otherwise insert) a new file into a container that already contains a file the new one will simply crunch the old one, and with external storage FM will manage all the changes itself.
Re: "once you drag and drop your file into the container, Filemaker stores the file for you in its folder"
–Yes, FM will manage everything on the fly. You can easily see this in action. Try this: (1) place the demo file on your desktop; (2) open up the stored container layout and drag a file into the stored container field. FM will instantly create a folder on your desktop in which it will store the file—if you open the folder you will see that it contains a whole series of subfolders, which is all part of the secure storage process it is using; (3) now click inside the container field, hit the delete key, then click outside the field. FM will now not only delete the file from the field, but will also delete the folder it created. It will not be in the trash, it will be gone completely—what FM giveth, FM taketh away.
Re: "this explanaition doesn't apply if you choose to insert a file into the container by right clicking on the container or choosing insert from the fil menu"
– Not quite. The storage process is the same; the only difference is that you get a dialog box and have to dig through directories to locate the file you want to insert.
Hope all of that helps you progress another step or two along the road.