This looks like a mac dialog, the windows dialogs are different, but somewhere, there is an option that specifies a page range. I suspect that it is not set to "all" pages.
I guess it's a bug.
Here's another screenshot showing more of the upper part of the dialog.
Ok, maybe it's not a bug, but it's still confusing and not consistent.
It turns out that to print the portal, in my case, seems to "require" you have the total number of rows you want to print set up in the portal. So if you have 20 records, you have to be showing 20 portal rows (in the portal setup).
At least this is what's happening on my layout.
The inconsistencies are:
1. You're saying "print all records being browsed" (the portal rows I want to print to pdf are all there. I see them!), and
2. Excel and HTML output create files with all the records without any messing with making sure the portal has enough visible rows for all the data (with no scrolling).
Why can't FileMaker "figure out" what "Records being browsed" means for the portal and print THOSE records without ME having to count up all the records and adjust the portal row count (in design mode, no less) so it "works"?
I don't get it.
1) This is quite consistent and expected behavior. It does indeed print "all records being browsed", but the records being browsed aren't the related records in a portal, they are the records that make up the layout's current found set. The number of related records in a portal could quite easily number in the 1000's or more in many situations. There's just no way FileMaker is going to be able to do handle such a situation. In some cases, we don't want those additional records to print as we are using the number of portal rows to limit what gets printed.
2) Exporting data to a file is a completely different process from printing or saving a PDF. Those options do not try to recreate the layout format as happens when your print or generate a PDF from the context of a given layout.
If you have a single portal on your layout, the simplest way to fix this is to set up a list view layout based on the portal's table. From the current layout, a script can use Go to Related Records or perform a find to pull up all the current layout record's set of portal records on that other layout. Fields from the parent record can then be included in the layout, such as in the header and footer, to provide a complete output of this information that is fully flexible in terms of the number of related records that need to be printed. The Invoices starter solution that comes with FileMaker uses this method to print invoices--which have a portal to Invoice Data on each invoice data entry layout.
A second best option (but sometimes necessary) is to make a copy of your layout and extend the portal to be many rows tall and then set it to "slide up" and to "resize enclosing part". It would be nice if layout elements could expand as well as contract to fit the available data, but this is not possible in FileMaker.
1. I am browsing 30 records in the portal, but it only outputs the number of portal rows defined. HTML and Excel have expected output (the records I'm browsing).
FMP should definitely be able to output the records I see in the portal. FMP's own dialog says "Records Being Browsed". I went ahead and did a GTTR from the parent to switch to the child layout and display the portal, but the same issue happens. Missing records on output.
This behavior is happening in list view.
2. Exporting to PDF (as well as File Save .. As PDF) both have the same exact issue records omitted. The output "format" of the PDF is fine; FMP is just ignoring most of the records I'm browsing in the portal.
I can't determine ahead of time how many child records might be in a portal so I don't see a way around this issue. If I set the portal to be 1,000 rows, then for most records, with say, only 10 child records, the resulting PDF would have 990 blank rows. Also, the user would not have access to FMP is design mode.
3. Based on the relationship in the database with the parent record (PK to FK), the portal layout has all the records correctly related to the parent row already (don't see the need to GTTR, but as I said above, I tried it anyway).
I easily got the data via a SQL command remotely, and can then print/save the results, as expected, but then, unless I do some actual programming, I would lose the container controls.
The bottom line is if I can't do a query (Find) in FMP and get a list of rows, regardless of size, in a Portal that all print out (just the rows in the query result), then FMP isn't much good to me for production work. In any other environment, this is just a "result set" you iterate over and output each row. Simple. I'm not sure why it's a "bridge too far" in FMP.
1) sorry, but I must disagree. Not only would that be very difficult to do, but, as I have stated in my last post, very undesirable in many cases. To Repeat, you are not understanding what "records being browsed" means.
I can't determine ahead of time how many child records might be in a portal so I don't see a way around this issue
Please read my last post again. I have described two different ways to handle this issue. The first method will work no matter how many records might be related to your current parent record. Other options are also possible. I have only described the simplest two.
And as I stated in my previous post, Saving as PDF and printing both use the current layout to "print" the resulting output. Export Records options cannot be considered equivalent as they do not try to recreate the current layout, just generate a table/file of exported data which is a much more straight forward proposition.
I created a report based on the portal and that looks nicer anyway. Saves as PDF perfectly. I never used (gulp, noticed) the "slide up" control so that was a good tip. Thanks!
For a basic listing, and "portal" ...."Finds", I should just use the "many" layout (like Orders) directly and not the portal - since the portal doesn't work with "Find".
Lots of great tips.
Thanks for your patience and for your excellent help! :)
I sincerely appreciate your insights from your extensive knowledge of this product.
P.S. My misunderstanding the portal (and the associated frustration) are also described at the end of this podcast: http://filemakertoday.com/filemaker-podcasts/37-filemaker-podcasts/334-fm-success-tips