I’m working with the Insert File script step for the first time.

When I specify “Store only a reference” and then Insert File, a subsequent GetAsText(:: brings back the following:

[color:orange]file:Example.txt

filewin:/C:/TestDir/SubDir/Example.txt

When I uncheck that option and then Insert File, a GetAsText(:: brings back only

[color:orange]Example.txt

What I want is the actual text contents of the file to be saved away in the container. With the option unchecked, is the file’s text actually in the container? If so, what calculation can get it out in order to display it?

BTW, with either of the above options, a right-click “Export Field Contents” places the file’s contents properly in the target file. Obviously, FMP is resolving, fetching and exporting independently of whether the content is actually in the container field.

Thanks in advance for any guidance.

When you specify “Store only a reference”, the container field contains a path to your file (or rather multiple paths) and sometimes additional information about the file (such as image size).

With the option unchecked, the actual file is embedded in the container field, lock, stock and barrel. In order to access the contents of file, the file must be opened first - and you cannot open a file from within a container (except some file formats, such as images, that Filemaker knows how to to open and display without needing an external application).

With the option unchecked, the actual file is embedded in the container field, lock, stock and barrel. In order to access the contents of file, the file must be opened first - and you cannot open a file from within a container

Thanks for the response.

Sounds like a real Catch 22 ... "I have it, but I can't let you see it." I can understand the idea of "opening" when it's an image or a PDF -- but why not have a way to get at simple text? I know that question is rhetorical since FileMaker decides these things -- but I'm hoping someone knows a reason for their (non)implementation.

I think the reason is that for plain text there is no reason to place it in a file, then place the file in a container - you can simply place the text itself in a text field (or even in a container field) directly.

You might look into the web viewer to display the text file, this also works for other file formats (as long as your browser can display them, although I find pdfs to be a little buggy)

The text from the file would then be avilable to filemaker through GetLayoutObjectAttribute ( "webviewerobject"; "Content" )

Just a thought! :qwery:

... you can simply place the text itself in a text field (or even in a container field) directly.

Well, I tested and, indeed, you can use a SetField to populate a container with text -- which a GetAsText can then retrieve. So the text inside the container is "different", depending on whether it came from an Insert File or from a Set Field. That seems odd to me, but "Oh, well."

If anyone has an idea for an ExtractTextFromFileInContainer function, I'd be interested in learning about it ... but I won't be counting on it.

Thanks again for the help.

You might look into the web viewer to display the text file

Thanks for the suggestion.

But can you explain this just a little more? How do I direct the Web Viewer field to the disk path/file? Or do I first Insert File and then direct the viewer to the container?

So the text inside the container is "different", depending on whether it came from an Insert File or from a Set Field. That seems odd to me, but "Oh, well."

I don't think it's that odd or different. When you insert a file as reference only, you are actually populating the field with a textual path to the file. The path can be retrieved using GetAsText() - but it's just text, so it could be anything.

I agree completely about storing the path. What I think is odd is when the text file is held in the container, yet you can't "GetAsText". Sorry if I didn't make that clear.

But a text file is not text - it's a file. You'd have to open it to see that the content is text (or not).

But a text file is not text - it's a file.

I'll have to defer that detail to FileMaker. A few more lines in their GetAsText function could probably work around that hurdle. Maybe someone will take a look. I'll submit it as a suggestion.

I do appreciate the insights you've provided. Hopefully, these posts will help others. The "view" into containers can be murky at times.

Here is a simple example that will display a file at a path you provide in a web viewer. Be careful, this has a tendency to be more than a bit quirky for some file types but in theory, should be able to display anything a web browser does.

DisplayFileInViewer.zip