Correct, that is how portals work, they can expand with the anchoring options, but sliding of objects is not respected for any object in browse mode (it's a popular requested feature though).
Although if you just need to reference one field from the "child", you could use a simple calc of:
List( RelatedAwards::AwardName )
to create a plain text list of the awards. You would need to filter the relationship instead of filtering the portal, but that may be an acceptable substitute for you to hide the empty rows.
You could also mock up a "horizontal portal", by having 10 smaller single-row portals aligned from left to right, and then setting them to start on row 1,2,3,etc.. This way they are all on the same "row". Then you could even use "hide object when" to calculate a hide condition on the portal. EG Hide object when:
Count( RelatedAwards::AwardName ) < 10
to hide the last portal
I've actually used that horizontal portal row method to have an awards "row" of icons before.
Thanks for the idea. This sounds like a technique I don't know about.
But, I don't understand what you mean when you say "...setting them to start on row 1,2,3,etc.. This way they are all on the same "row". "
How can they start on row 1,2,3 etc AND be on the same row?
This is a handy trick Mike has suggested. The portals are placed side by side across your layout. Each portal displays just one row and from left to right they display row 1, row 2, row 3 etc. Thus they give the appearance of a horizontal rather than vertical portal.
There is a setting under portal settings as to which “row” the portal should start on. This allows you to offset multiple portals that are next to each other. Think of a grid view of an image gallery ordered from 1-20. If the order of images went down each column, the first portal would be 1-5, the second portal would start at row 6 and go to 10, row 11-15, 16-20. Essentailly in each of those 4 portals, you set the starting row to be offset so it gives the appearance that you are loading lots of records in one area, but are doing so with native FileMaker portals.
Another and simpler option:
set up a list view layout based based on the awards table. Put fields from members into:
1) a subsummary part sorted by member ID if you want to list multiple members.
2) header, footer and/or grand summary parts if you only want to show one member at a time.
Note that for 1) you must have your records sorted by member or the subsummary parts will not be visible.
THE awards portal contains the 2 highlighted entries below.
In browse mode it looks unnecessarily filled with blank portal rows; ugly.
When I print this report it looks great; collapsed.
The report is based on Members and has subsummary breaks on:
Age in Years
As noted, depending on the sort I can get a sub summary report that works but looks ugly.
If I base the report on Awards, and produce a sub summary on Awards I get only a single Award entry.
I don't see it.
Why do you say "Thus they give the appearance of a horizontal rather than vertical portal."
Doesn't my example portal show that it is a HORIZONTAL portal?
My fields are:
Are you suggesting that I put those field in a vertical portal (Date on top followed by Award and the Notes below)
Sorry I just don't see it.