Actually, this forum serves as a great example!
There are different forums (tables) that display only the posts (fields?) that are related to them.
One view displays all related posts and code is added all around them!
That looks like C++, not psuedo code and I can't quite picture what it is supposed to tell me.
Do you know how to add portals to your layout?
A portal to table B on your table A layout can list all related Table B records. A portal filter can then reduce that list further to display a subset of all related records if that is needed.
Thus the relationship between Table A and Table B plus any filter expression you might put in place on the portal will control what records appear in your layout.
Sorry about that... let me rephrase it as much as I can.
Let ( $$X = 0; "" )
While $$X is less than the total number of related items from TableB do the following:
Display TableB's $$Xth Name field and add 1 to $$X.
Try it in plain English.
I read that as: "display all related items from Table B".
and have no idea what purpose is served by $$X--which appears to simply count the number of related records.
Yes, exactly. I want to display all related items from Table B and count them and do other stuff, as previously mentioned.
Also, a portal is all well and good for displaying all related items, but I can't DO anything with it (as far as I know).
On the contrary. Data in the portal is fully editable. You can edit data and delete records from it. You can add new related records if the relationship options permit it.
Sorry, it is manually editable, but it is not programattically editable, if that makes sense.
My goal is to programmatically build a page. I can't be manually entering the same information in every field for every record.
No it does not. It is accessible to scripts and calculations as well. A script can access the data in the portal or from the related table. A calcualtion can access the data in the related table.
I can't be manually entering the same information in every field for every record.
I see no reason why you would need to do that. In fact, a relational database is designed to avoid that issue.
I suggest taking a big step back from the nuts and bolts details and describing what you want to produce in plain English. Then we can suggest how you would set that up in FileMaker.
Did you see my dessert example in my original post?
I want to view all desserts. I want to have a calculation field that displays the total number of desserts. I want to be able to call up the fifth dessert or the one hundredth dessert and display it's name, it's ingredients (expanding on their simple example), it's weight.
All of that can be done with a portal and scripting. It can also be done without a portal.
My goal is to programmatically build a page.
Is what is not clear to me. i can picture multiple ways to do that to greater or lesser degree.
Can you give any examples that relate to the examples I've given?
I'd much prefer a much clearer example of what you want to do.
It's possible that you are describing something like the search portals in this demo file: https://www.dropbox.com/s/0pm1gdqcfi2ndpv/EnhancedValueSelection.fp7
I could also be completely wrong about that.
If you are using FileMaker 12, open this file from the File menu to get a copy converted to the Fmp 12 file format.
Thanks for the file! I want to take the list of products and put them in a computation so they can be delimited by a comma, tab, or whatever I want.
So it could be...
Screw driver,5" Screw
Screw driver :) 5" Screw :)
<AWESOME>Screw driver</AWESOME> /|||\ <AWESOME>5" Screw</AWESOME>
or anything I want.