Portal Sliding/Printing Problem in FMP7

[Pfhorrest]

Hi all,

I'm a very small developer for a little company that's been running FM5/6 for quite a few years now. I've rebuilt and maintained most of their database in the two years I've been here, and now we've decided to upgrade to FMP7. The transition has been very smooth so far, much less trouble than the documentation on the FM upgrade process had lead me to believe - for the most part, I just imported the FM6 database folder and it all works.

But we are having some problems, and I need some help. The biggest problem we have at the moment is with a print view in our Invoice system. Here's the setup: the Invoices file stores a few data points like order date, ship method, etc. It pulls customer info from the Contacts file, line items from the Sales file into a portal, and payment info from two different relations to the Payments file (Payments From, which is normal money applied to the invoice, and Payments To, which is money transferred to somewhere else, or refunded) into their own portals. There are then some calculation fields dealing with these sales and payments, etc.

The problem is with the Payments portals in the Print view. The customer data is at the top, the line items in a long portal spanning the page break (set to slide and reduce), the two Payment portals are side-by-side below that, and the calculation fields all side by side on a line below that, and a notes field at the bottom of the second page. The top portion, through the line items and the text boxes labelling the payments portals print fine; but the Payments portals, and everything below them, do not print. The bottom of the first page is blank. The second page, even when there are very few line items and it should all fit on one page, will print the bottom of the notes field or sometimes the notes field and the bottoms of the calculated fields. It's as though it's breaking the page well before it reaches the end of the available page space, and then begins printing the next page before the page actually starts, resulting in a blank space on the first page and missing data on the second.

I just did a test with a very long list of line items that wraps across pages, and in that case, the rest of the items below the line items portal prints just fine.

Any ideas?

(Footnote: I know it's bad forum ettiquite to ask this, but if anyone wouldn't mind emailing me a copy of their reply to forrest [at] west [dot] net, since there doesn't seem to be an option on this forum to do so automatically, that would be much appreciated. Thank you.)

[Pfhorrest]

Addendum...

If I reduce the number of rows on the line-item portal so that the *first lines* of the payment portals fit on the first page in layout mode, the first page prints just fine: everything slides up and fits just fine, for small invoices. HOWEVER, any parts which, in layout mode, begins on the second page, ALSO prints on the second page. So now I can print small invoices fine, but I'm getting duplicately printed data, and anything with 8 or more line items won't print all line items now (portal is too small)...

[-Queue-]

It is not recommended to print portals. Usually the printing is done in the line items file with related fields showing data from the invoices and client files/tables.

[BrentHedden]

I'm with Queue -

I've had nothing but headaches and the such from trying to print portals correctly. I have found no satisfactory way of doing such.

Portals are great for viewing only. If I need to print the same information, I'll use a separate "List View" layout, usually with a header and footer.

[Pfhorrest]

The problem here is that I'm printing one type of document (an invoice) with three different portals AND some non-portal information on it, and in some cases that all may not be more than one page's worth, so it seems like an awful waste to set up the invoicer that will print four pages for data that might fit on one. The hack that we've got set up right now is that it will print the first few lines of related data in portals, and if it's more than will fit on that one-page invoice, we print a list from the related files and attach it. But that seems awfully inelegant.

[-Queue-]

Why three different portals? What information is contained in each?

[CoZiMan]

-Queue-

This flies in the face of the rationale for the "Seperation Model" that's being discussed elsewhere.

I am just finishing a new project using this "Seperation Model" for the GUI and now I'm wondering exactly what will hapen when I start to run the output. I'm going to begin testing output from the GUI file today and see if it holds up on multi page documents.

Can we cross post this to that forum and see what happens in the discussion?:

TTYL

[-Queue-]

Chris, are you saying that the separation model forces the printing of portals, and if so, why? I have had little interaction with such a model and fail to see why it should be a problem.

As long as you aren't double-posting, sure.

[CoZiMan]

It's not that the model forces the use of portals, you may just end up working on all the data in portals for the GUI file. I'm still testing this to see what happens to the output logic. Seems like I won't need portals.

[vinegar]

The solution is to create a list of values basing on the different relations, then using the function ValueListEntries() (this is a translation from the german version, maybe you have to modify the expression). By this way elements of the relational tabels as well as of the present can be shown on one page. The solution comes from Mr Dr. Jens Teich, submitted to the FM-Forum in www.filemaker.de.