The context for the HTML text shown on the right may be different from that referenced by the web viewer inside the portal. And the relationship on whichn the portal is based might also delay/prevent automatic updates of the data referenced by the web viewer.
What is the purpose of the portal here? On what relationship is it based?
I have two tables: DocMain and DocRls.
The main layout is from the DocMain table.
In the "Main Document Tab", there is a a portal showing a listing of the various Releases for the Document.
The portal in the "View Composed" tab, is just looking at the DocRlsComposedContent field. The composed content is just an HTML version of the main body of text which I have in a separate Text field. So the Composed Content is a calculation from that field.
I am attaching the Layout mode of what I had before.
And what is the relationship between DocMain and DocRIs? What do you use for match fields? Is it a sorted relationship?
If you are using this type of one to many relationship:
DocMain::__pkDocMainID = DocRIs::_fkDocMainID
Then I don't see any need for the web viewer as you can list all needed data from DocRI's in the portal without using a web viewer and the HTML tagged text.
<quote>If you are using this type of one to many relationship:
DocMain::__pkDocMainID = DocRIs::_fkDocMainID
Then I don't see any need for the web viewer as you can list all needed data from DocRI's in the portal without using a web viewer and the HTML tagged text.</quote>
The information I want to display are basically documents with bullets, numbered indents etc. (in other words with significantly more formatting that I am able to utilize in FMP) They now exist as separate Word files. I want to dynamically create the document with additional content from the database entries, such as the Release Numbers, approval names and dates etc.. That way, the generated content can be printed as a standalone document.
I thought the WebViewer would be the easier way to go. It doesn't seem like it is feasible. I can still have the output generated as an HTML document, but it will be exported out as a separate file.
I don't see why what you want to do isn't working. I can't see enough detail to see how it is intended to work. What I see looks like a typical HTML table but I can't really see what is supposed to be the full data source for that table, just a few bits and pieces.
I was simply questioning why it was necessary to build that layer of complexity into your database.
Your example doesn't show any such special formatting--just a table like view that is possible without resorting to a web viewer so I asked to see if the best solution might be to simplify what you have shown here. (and indenting, bulleted lists etc aren't totally impossible in FMP though producing that result would not be a simple thing to accomplish.)
Well, I don't know how else to say it. I was expecting the web viewer to behave just like any field I would have in a portal. I have a calculation field. The output of the calculation is essentially to add HTML tags. If I view the calculated output in a text field within the portal, I see it perfectly well enough as HTML, with tags and all. I can export the result of the calculation field as a standalone HTML file, which automatically opens in a browser with no problem.
That same exact calculation field value, when I choose to look at it through a web-viewer, won't refresh beyond what it has for the first portal record. My assumption was that that I should just point the web viewer to the related field, just like any other portal data, it should be able to automatically refresh/relead.
I just experimented to have the webviewer show the exact record I want in a separate layout triggered with a button running a "Go To Related Record" command, and it seems to work. Apparently, it just won't automatically refresh if the viewer is within a portal. I can't seem to understand why. I guess I will have to get my users to point back to the original layout instead of going tab-to-tab within the same layout.
The problem isn't that the webviewer will not refresh. You can not put a web viewer into a portal.
From the above link
You can’t place a web viewer in a portal. If you place a web viewer on a portal, the web viewer appears as an object on the layout that overlaps the portal.
Thank you S Chamblee.
Apparently I found out the hard way.
Most obviously thank you too Phil.!!
Basically, I am looking to make available a well-edited text like a word document from within Filemaker. I am looking at procedures and the like. The document approvals, and links to other referenced documents are going to be within Filemaker. I wanted to have the users actually read the formatted document within Filemaker.
By well-edited, I mean things like indented bullets etc... (Section 4.2.a.... etc...). I don't believe I can get this kind of formatting capability within a text field. But I thought if I can save the html source text, then I can display the well-formatted document within the viewer. So far, It does work as intended, except that I can't put a Web Viewer in a portal.
Now, if there is a way that I can save a word formatted document within a container, then extract and display the content as-is, with additional document information added to it dynamically, I'd be set. I just can't figure out a good way to do it outside of a web viewer. (I know Filemaker is not a word processor)
I don't believe I can get this kind of formatting capability within a text field.
Ah but you can. You can set tab stops, indents etc for a text field in the Inspector's appearance tab.
Another option would be not to use the portal. A list view of the records in the portal with the other data included in different layout parts such as the header, summary and sub summary layout parts...., could list multiple web viewers and you would not be dealing with the portal limitation.