Hmmm, that would be: Order----<Product----<ProductDetails (---< means "one to many" ) if I understand you correctly.
You're on the right track. The starter solution does illustrate what you need. Notice that the print layout does not use any portals as portals can be troublesome to use for printing and thus are better off avoided in such layouts when possible.
Base your layout on ProductDetails. Given the above relationship, (If I've correctly interpreted it), you can add fields from Product in sub summary parts "when sorted by product ID" and fields from Order can be placed in the header, footer, leading grand summary or trailing grand summary layouts parts.
You can use a script that performs a find or uses Go To Related Records to pull up the Details records and then sorts them by Product ID to group tham and make the sub summary part visible.
When you add a sub summary part to your layout, you must sort your records by the "sorted by" specified for that layout part or the sub summary part will not be visible.
Thanks for the reply,
I managed to figure it out. I basically just used the Invoice Template and added a portal for Product Details in the body section along with the Product information. After which I did the script you mentioned and was good to go.
Now to figure out why it's so slow on the iPad 2...
Not the approach I'd use. I see why, it's a simple adaptation of what's already there, but your portals will limit you to the maximum number of rows visible in the portal. You can set the portal to be many rows tall and then have it slide and resize and this may be sufficient if you specify a large enough portal, but you still have an upper limit and the fields within the portal row will not slide and resize, just the portal as a whole.
A list view layout based on the details table does not have those limitations.
Hmm for my particular situation it worked out great. I did use list view, but just for the Product table instead. You're definitely right about the portal limitations though. Luckily for me the user was only ever going to put a maximum of 5 records for product details anyway :).
Perhaps I will play around with it after the work is done to try list view for the Details table and see if I can get more of what I wanted. Thanks for all your help.
Also, quick question while your here. I noticed that performance on the iPad is largely dependent on font size and text field size... is that a correct assumption or is that just something that could be on my end?
I don't have an iPad or an iPhone so I don't know. I haven't seen any reports that font size was a factor, but that's all I can tell you. iOS devices are by nature much slower than full up computers and other posts in the Go forum indicate that FileMaker Inc. is aware of this issue.
I believe I saw this question recently posted (by you?) in the FM Go forum. That's the best place to compare notes with other Go users and techs like TS Gal.
Well I solved it. Literally, the only thing I changed was the font size, and the physical size of the fields. It made things a lot faster. If you haven't seen any reports like that, consider mine the first then :)
BTW, I did see a report somewhere on the forums of font size affecting the performance...that's where I got the idea in the first place.