My database has tables address and person. Every person has a
addressId. The adresId links every person to exactly one address.

I want a create a layout for printing. Every page should start with
address informatiion, followed by a list of persons linked to that
address.

In a layout (for view and edit purposes) I have a portal showing the
persons linked to the current address. When I click on a person a
script shows all information about that person in a different person
lay-out.

But for printing pupose I need one layout with all persons (not
limited by a maximal number ofl lines in a portal). What makes it
maybe even more difficult is that the report should contain
multi-lined fields for every person (no parts covered, no
scrollbars). Therefore the length of the print of a person varies a
lot

Does Filemaker 10 supports this kind of reports? Any pointer to a
solutions is welcome.

Kees

"Kees" <xxx@yyy> schreef in bericht
news:9iqi46tsppg5lo314ftj3144ck4qeodvrl (AT) 4ax (DOT) com...
The listview and sliding seem to answer you questions.
Set up a layout with all fields as needed.
Make it as small as possible, and stay within righthand print-boundary.
Make the size of the field as large as the largest you will ever need.
Then select all fields and from the menu select sliding objects. Both
sliding left and sliding up. Sliding up with all objects above and select
resize enclosing parts. This will ensure that all empty space will disappear
when printing or previewing.
In browse mode set the layout to view as list. To preview the results switch
from browse to preview.

--
Keep well / Hou je goed

Ursus

"Kees" <xxx@yyy> wrote

You shouldn't use Portals for printing anyway.

First you will need to create a Calculation Field in the People Table to
copy the address from the Addresses Table so that each person's record has
that information within it. (Depending on how the addresses are stored, you
may need multiple Calculation Fields, i.e. one for Street, one for City, one
for Zip Code, etc., or just one new Calculation Field that combines these
separate Fields.)
i.e.
c_Address Calculation, Text Result, Unstored
= AddressesTable::AddressLD

Then you can create a new Layout using the People Table. This Layout will
need to have a Sub-Summary Part at the top to display the Address and then
use the Body Part to display all the people with that address. The Layout
would look something like (you may need to change the following into a
non-proportional font like Courier):

Address-sorted Report
//


[c_Address]


[First Name] [Surname] [Multiline Field]
[ ]
[ ]
++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++


Page #


The [] denote Fields and the ++++ lines could be a line drawn using the line
tool just to visually separate each person's and addresses' data (you could
also set-up the report to force a Page Break for each new address).

The Multiline Field(s) (and the Body Part) will need to be stretched as tall
as needed for the MAXIMUM amount of data it will hold ... but beware of the
page break (on some printers the page break will cause data within that area
to not be printed). Set the Sliding options for Multiline Field(s) AND the
++++ line beneath it to "Slide Up (based on all above)" and "Shrink
enclosing part".

Now you can Find the Records you want to appear on the report, sort them by
the Field c_Address and then Print or Preview this new Layout. This process
can of course be scripted and accessed by a Button, menu or keyboard
shortcut.


Helpfull Harry )

On Sat, 24 Jul 2010 09:51:03 +1200, "Your Name" <your.name (AT) isp (DOT) com>
wrote:

-- snip ---

Thank you for your answer.
The database has a relation. This relation makes it possible to lookup
the address-values, like street, zip code for the current person.
In your answer you create calculated fields. Is this nescessary even
when there is a relation? In my database the adress table has
approximalty 40 fields.
I have put related addressfield in layout mode in the address
sub-summary (I know, not quite what you said). Now, if I go from
layout mde to browse mode, I can see the adress. I get
page1: person 1 Address 1
page2: person 2 Adsress 1
page3: person 3 Address 1
page4: person 4 Address 2....
This is not what I want. I want 1 address followed by 3 (in this case)
persons.

When I print this layout the whole address part is gone. I can only
see the persons info.

Do I have to create calcutated fields in the person table for every
field in the addres or could something else be wrong?

Kees

"Kees" <xxx@yyy> wrote

It's not really necessary to create the new Calculation Field(s), but it
tends to make it easier to understand what's happening when everything is in
th same Table (when possible).

BUT,
the Summary part of the Layout does need to Sort by the address, so if you
storing addresses as individual parts using Fields like StreetNumber,
StreetName, StreetType, then you will need a new Calculation Field in one of
the Tables to combine these into a unique address (it doesn't matter which
Table).
i.e.
c_Address Calculation, Text Result, Unstored
= StreetNumber & " " & StreetName & " " & StreetType



40 Fields for an address?!?!? If you want to create the new Calculation
Fields in the people Table, then you of course only need Fields for the data
you want to display on the Layout ... you're unlikely to need ALL the Fields
from the Addresses Table.



This sounds like you may be forgetting to Sort the Records.

The Sub-summary Part needs to be set as by the "address" Field (probably the
first line of their address is best, e.g. "14 XYZ Street" or "15 ABC Road")
and then you need to Sort the Records by this same Field before previewing /
printing the Layout.

You may also want to check the Sliding options - the multiline Field(s) and
everything below them (other fields, lines, boxes, images, etc.) in the same
Layout Part must be set to Slide Up on All Above and to shrink the enclosing
Part.


Helpfull Harry )

On Tue, 27 Jul 2010 09:06:52 +1200, "Your Name" <your.name (AT) isp (DOT) com>
wrote:

Thank you for your answer. The problem was indeed the sorting. Now
everything works fine.

The address table contains a lot of data about families. I wanted to
describe the problem as easy as possible, therefor I initially left
out the 40 fields.

But anyway, everything works okay!

Thanks!
Kees