adam sugerman

I'm having an unusual problem printing a layout that displays several
portals. This is a multi-table database for managing a company's
assets in FP 7.0v3.

The layout is in a table called Ventures and the portals are Do***ents,
Managers, Companies and Terms. I've laid out all the portals to have
about 20 rows with sliding applied to all items on the layout, so that
if a portal only as three rows, the printed do***ent elides the empty
space.

Despite this, the bottom two portals don't seem to slide correctly,
leaving big gaps of space when there aren't any records (not even empty
records). In addition, sometimes there'll be a big gap between the
bottom portal -- Terms -- and the field that follows it -- Notes --
then on the next page the items from the portal will show up with the
first couple rows run off the top of the page and the Notes field
repeated below it. Not the expected behavior, to say the least.

Two questions: 1) How do I get this to work properly? 2) Is there
another solution for designing a layout with data from multiple portals
that doesn't include having the portals themselves on the layout?
Obviously if there were only one portal, I could design the layout in
the portal's table, but with four, what's the work-around?

I should note as well that the layout is simply a Body and Footer;
there are no graphic or text objects that would be interfering with
sliding, either visible or hiding behind objects; and the system is Mac
OS X.

Any help would be greatly appreciated.

Best,
-S.

42

In article <1129760174.850779.214750@g47g2000cwa.googlegroups .com>,
sug@evworks.com says...

Portals on printouts that span multiple pages and slide around rarely
work well. One thing to remember is that 'sliding' printing will always
leave space between portals intact, even when it works it just collapses
'the size of the object'. So if one of the portals is empty, even if it
collapses to nothing it will still have extra space between it and the
next portal.

You may also need to 'reduce the size of the enclosing part' to resolve
some of the issues.

Unfortunately large portals just don't seem to slide/condense well, and
the usual advice is to avoid using them.

Given that you are trying to show data from multiple dynamic portals in
a single report you are right, you can't build the layout in the portals
table however there are a couple options:

1) Do you really need it to be all on one report? If the report is
large, and the portals each may span multiple pages it might make sense
to just create it as 4 distinct reports:

script a batch print:
pritn report 1
print report 2
print report 3
print report 4

2) If the amount of data is reasonably small, you could consider
exporting it all into a 'utility table' for handling the print out.

Define separate fields for each import, and then on the layout, overlay
each set of fields as needed. It sounds kludgy (and it is) but for
reasonably small data sets ( say <100 to 200 records) the performance
hit for the export is minimal, and it works brilliantly.

e.g. you have 2 tables:

addresses, friends

addresses = {addressline1, line2, city, province, postal code}
friends = {name first, name last, phone number, email}

utilitytable = {type, al1, al2, city, prov, postalcode, nfirst, nlast,
phonenumber, email}

(use all text fields regardless of what they are in the real database)

script:
delete all records in the utility table
get found set of addresses to print
import address to utility tables "address" fields
replace type = "10-address"
get found set of friends to print
import friends to utility tables "friend" fields
replace type = "30-friends"
new record
set field type "20-blankRow"
find all
sort by type
print

the actual layout will be a simple body, with ALL the fields on it. The
friend fields will be blank for the address rows, and vice versa so even
though all the fields are on 'every record' you can't see them, and for
printout it doesn't matter.

You add header rows by creating new records, and settign the fields
apprpriately... e.g. to put a header row between the blank row and the
friends row:
new record
set field type = "25-friends header"
set field nfirst = "First Name"
set field nlast = "Last Name"
....
....

You can also make the record types vary in height if necessary by using
the sliding/printing options.

Anyhow, its a pain because of all the overlapping fields, and you'll
want to "group" the fields so you can drag an entire "layout" in and out
to work on it.

Of course, if it happens that the portals are all very similiar, there's
no reason you can't reuse the fields over and over.

-regards,
Dave

adam sugerman

Ooof, that does look kludgy, but thanks for the thoughtful
recommendations, Dave. I'll see if I can adapt your ideas to the
project at hand and let you know how it comes out. Really appreciate
the suggestions.

Best,
-S.