Do you already know the 'Sliding' function within Inspector?
Guess you'll use Option 'Sliding up …'
AND [ x ] Also resize enclosing part
It's kind of a try & error: apply function on objects and get in Preview-Mode.
Though you'll switch a lot between Layout- AND Preview-Mode.
Sliding function is not visible in Browse-Mode. That's why you have to check results in Preview-Mode
I'm assuming what efficientbizz says above will resolve your problem, however I ran into a problem just a month ago with a report I was generating, so I'll share this in case you already know about/use sliding. I had sliding up turned on for two portals and all objects within them, but they didn't slide or remove blank rows when printing. I read somewhere that suggested simply remaking the report in a new layout, and -bam- it worked like it was supposed to. Whatever error was occurring was tied to the layout.
Thanks for taking the time to reply.
The portal cells are remaining at the same size and the content isn't moving. I wanted to check if portals can behave like fields.
Once again thanks for your responses
It unfortunately looks like it's working correctly. When it comes to portal rows, I believe that sliding only applies to blank rows; the portal height remains the same. Filemaker explains it here:
However, as they suggest, if there are no other portals in the report, you could create a new List View report from the Meeting_Publisher 2 table, and instead of portal rows you'd have each line in its own row; rows on a list will reduce in size when sliding is activated by using the "Also resize enclosing part" function.
organize the report on a LIST layout showing records from your portal lines.
Footer- and Header-Area allows unlimited for all needs.
You also should try try some tricks with "Subsummary-Areas" when sorted by ...
Which is almost always the correct way to handle this. Portals are primarily UI tools and not really amenable to printing.
Totally agree. To quote from FM support page: "portals were not designed for printing". Use portals for on-screen display only; design your print layouts separately. I know you CAN print portals satisfactorily in some circumstances, but it looks like this is not one of them.
Thank you all for checking this out and the positive suggestions.
For sake of completeness, there is a way to do it on your initial layout, but I don't recommend it:
You can have a big text field, calculation, unstored, sitting on the layout instead of the portal and set to shrink upwards.
This calculation pulls the data via SQL and uses CHAR(9) as separator for fields. You then format the text field on the layout by setting tabs correctly.
… last challenge would be to have the datas represented with a WebViewer with a very sophisticated html formula.
Certainly not among my best recommendations but just to sum things up
I am not sure we can definitely say that Portal is not design for printing...
About sliding, the fact is that you must choose between slide to adapt number of row OR to adapt height of row themselves. This choice is not so easy it is why in a *perfect world*, we should be able to get both .
As pointed out previously by price, if you want to print more than one related table with many record on it, list view is not really a solution.
And it is why i sometimes used repeating calc fields for this specific printing need. The formula is like GetNthRecord ( Extend ( <RelatedField> ) ; Get ( CalculationRepetitionNumber ) )
The key is that Repeating Fields slide both : number of repetitions AND height of repetition.
Personnaly, i enjoyed it .
Re: "I am not sure we can definitely say that Portal is not design for printing..." FileMaker say this themselves on their own support page.
Re: "if you want to print more than one related table with many record on it, list view is not really a solution." Depending on the file setup this may be possible using different sub summary parts for different records.
1. I said that because if the portal IS sliding… But okay, i am not engineer nor documentalist by FMI...
2. Don't see at all. The fact is that a layout only have one main table. If multiple related tables have multiple records, the sub summary part doesn't help to me. Or did you make an allusion to the new summary "List" field ?