Printing from a portal

[adyf]

I have used a portal on a layout for use as a report and find that when I set the portal to display 25 records then that's all that will be displayed when I enter preview mode. By using the scroll in browse mode I can scroll through all the portals related records even though it only displays 25 on the screen at once. Thought it would work like this in preview mode too.

I have found a workround although I'm not convinced it's too clever. I can over estimate (flaw!) the number of records that I think I will need and then set the portal to display that amount and then set the portal print options to reduce enclosing part which works. I guess the flaw is that if there are several hundred related records in the portal thenI will eventually reach the maximum allowed body depth. Could someone offer some advice please?

[Lee Smith]

Portals are not meant to be printed, they're meant for viewing your data from a related record. Many developers have tried to work around the limitations of the portals, and after a lot of hard work, few have gotten the results that they desired.

Set up your report in the file where the actual data resides.

HTH

Lee

[adyf]

Lee, thanks for your reply. I was afraid that you were going to suggest this. The beauty of using the portal was that it displayed the set of records I need for the report by way of the realationship, automatically if you like which is good. Is there a way to do this without a portal in the table where the data actually resides without a script to perform the necessary find? I would like to find the records for the report from a parent table if possible.

[Lee Smith]

Read about the Go To Related Record GTRR script step (available as a script step or when you create a button). GTRR, will set up your found set in the manner you describe.

Lee

[Rick Whitelaw]

I print portals all the time. The situation that comes to mind is a contract form that can have anywhere from two to perhaps a hundred names on it. The first page has a number of fields from the "Contracts" table, but the names, addresses and fees for each person are portals. Page one has room for, let's say fifteen names. So this portal will be from Table NAMES and records 1-15. This portal is always set to fifteen records. Subsequent pages have room twenty-five per page. So . . . NAMES 16-40 etc. None of these portals is set to scroll of course. So this layout, when all the boilerplate is included, consist of perhaps a dozen pages. The trick for printing properly is to set up a print script that only prints pages that contain data. This can be done along the lines of getting the Count of related records in NAMES and scripting the number of pages (and which pages) to be printed.

That's a long-winded way of saying that portals are fine for printing as long as the scroll bar isn't used. Printing something like a contract involving a large group of names is certainly a one-to-many situation that actually requires the use of portals. And a contract , even these days is almost always printed and signed!

[comment]

So this layout, when all the boilerplate is included, consist of perhaps a dozen pages. The trick for printing properly is to set up a print script that only prints pages that contain data.

And the advantage of doing all this work is … ?

[Rick Whitelaw]

Comment,

Not much work at all. Advantage? I suppose having a printable contract that deals with a large amount of information while only having to enter a few fields of data! Everything else is drawn from already existing data. What's the alternative?

Oh, and I forgot. So you don't print blank pages and you don't have to wade through the OS print commands selecting print page 1 then page 6 etc.

[comment]

What's the alternative?

Print from a list view of the child table.

[Rick Whitelaw]

Of course. However, as I mentioned in my vague description of page one, it is a situation where data from the parent table is on the same layout as data from the child tables. BTW it works really well.

Rick

[comment]

it is a situation where data from the parent table is on the same layout as data from the child tables.

I am not sure I understand the distinction. You can place data from the parent on the layout of a child - a sub-summary part by parent is the natural place for it.

I am sure it works really well for you - it's just about 100 times more complicated than the alternative, and I still don't see any advantage to it. OTOH, printing from the child table allows each child to have only the necessary height, while portal rows have a fixed height regardless of their content.

[Lee Smith]

Print from a list view of the child table.

Took the words right out of my mouth.

Since the addition of the Table View, sometimes I wonder if the list view has been forgotten?

Lee

[bruceR]

Portals are not meant to be printed,

I don't buy that statement. Printing portals has limitations; like so many things in FileMaker. It is important to understand those limitations; and make choices. Staying within the found set and going to a layout designed to be an N-page print layout is an easily workable alternative. I agreed that printing from the item layout is generally preferable and in any case, is a skill that a developer should be able to understand and apply. No cosmic destiny is involved, however.

[Lee Smith]

I don't buy that statement. Printing portals has limitations; like so many things in FileMaker. It is important to understand those limitations;

That's okay, there's no charge :-)

Would you be insulted if I told you I don't buy yours either.

IMHO, just because something can be done, doesn't mean it's the right approach to getting it done, especially when you consider the skill level of the person asking the question.

BTW, I never said it couldn't be done. I merely pointed out the intended purpose of the portals, and that there are better ways to accomplish what they were trying to do.

Lee

[bruceR]

"The intended purpose of portals." Intention. Wow.

Well, WHOSE intention? There is no intention and there is no intender. Who do we have to keep happy when building our solutions? What evidence is there of intention, and why is your interpretation of this divination the only correct interpretation? If we are going to imagine what purpose is served by features; and WHOSE purpose is served by presenting these features to us; then one could argue that the ability to control starting row of a portal intends for multi-page printing and controlled portal breaks.

There are some parts of building a multi-page solution that are in fact easier when using controlled portal breaks. There are benefits of child-table printing methods.

[adyf]

Read about the Go To Related Record GTRR script step (available as a script step or when you create a button). GTRR, will set up your found set in the manner you describe.

Lee

Lee, thanks for this although I should have known this myself having used GTRR before.....doh!

I'm using GTRR and getting the correct related set of records. Now I need to sort them in the correct order. I have built a script with GTRR as the first step and now added a sort step. This is where I'm having fun, I think I know how the database needs to sort these records but it's making it do it that's difficult. I'll try to explain.

I have the following ERD:

Route Packs ->RP_RPS Join Table<-Route Pack Sections->Locations

I am clicking my GTRR script button from (Route Packs), which is giving me the correct related set of records in (Locations).

Whenever I add records to (Route Packs) a record is automatically created in (RP_RPS Join Table). I have created two records in (Route Packs) using some of the same related records from (Route Pack Sections). For the sort, I am sorting by RP_RPS Join TableID from the (RP_RPS Join Table) and then by sort code from the (Locations) table itself.

The problem is I somehow need to bring Route PacksID into play which is also present in (RP_RPS Join Table). I need the sort to only use RP_RPS Join TableID for the Route PacksID of the Route Pack that I am currently in. I don't know if it's an issue but I have (RP_RPS Join Table) in table view.I beleive I am knocking on the door with this but can't quite get in.

[Lee Smith]

Well, WHOSE intention?

FileMaker's

http://www.filemaker...ayout.9.25.html

I don't doubt that you have some wonderful examples on how to do this. It might be nice if you posted an article on your technique, possibly with some examples, so that others can learn and benefit from your vast experience.

I don't think it's proper for us to continue to discuss this here, but I would love to see some examples of your's, either here in the Articles, Tips, Techniques & Solutions topic, or a link to where you have posted examples.

Enough said,

Lee

[Rick Whitelaw]

I should point out that the actual look and layout of the contract I spoke of is an already existing physical document that needs to look exactly the same. The record height, for example, is not negotiable. The look of the whole document is pre-determined. Not sure if this is relevant.

RW

[comment]

Not sure if this is relevant.

Only to the point that when printing from a list view, you have a choice whether to set the objects to slide (i.e. adjust the record height) or not.

[bruceR]

By the same interpretation of intention, we are prohibited from using single-row portals with FM11 filtering to display summary data for a filtered portal. We are also prohibited from using the single row portal visibility technique to show/hide buttons or other objects. We are narrowly asked to determine that printing is not displaying. I think this is all reading way too much into a single line of a help page. As for an example - read message 5. This really isn't that difficult. See Invoices 2 Page in attached example.

Invoices.fp7.zip