Found sets do not "contain layouts". But more than one layout can refer to the same table occurrence and thus will have the same found sets as long as they are all in the same window.
What do you mean by
I have a proposal layout set up so it can extend to a different layout if the space is needed.
A single layout can print out with as many pages as needed for your found set so long as the space needed for a single record does not exceed the fairly large maximum layout size, so I have to wonder how you've structured your table and the layout.
I have built what would probably be considered a very crude database. I have a contact table, a business table and a proposal table. A business can have many contacts and many proposals. Our proposals can very greatly. They could be a single item, a list of items, or a long description of what is to be done with a single price. This is a constrcution type business. I have may proposal set up on two different layouts, a one and a two page. Each line on the proposal contains separate fields, a quantity, description, price, & line total. Each is a seperate field, and each line has all four of these fields. So the body of my 1 page proposal has around 100 fields and if those are not enough I have a button two take you to the 2 page layout whixh has another approx. 100 fields. So some proposals you only need to see the one page layout, and others may require the two page. All the proposals exist on both layouts. When I search for proposals related to a particular business, I would like to show the the proposals that require one page as well as the ones that require two pages, but without the one page version being visible. I hope that makes a little sense.
It does make more sense, but we need to clear up a few details:
All the proposals exist on both layouts.
Actually, the proposals are records in a table. Since both layouts reference the same table, any given proposal can be viewed on either layout.
If you are trying to print out a found set of proposals with some from the two page and some from the one page layout, this cannot be done from a single print job, but scripts can print your proposals one at a time, selecting the appropriate layout for each or you can perform a find for just one page proposals and print them on the one page layout and perform a find for two page layouts and print them on the two page layout. This can also be scripted.
But I think you need to take a much closer look at the design of the tables used to produce these proposals.
Each line on the proposal contains separate fields, a quantity, description, price, & line total. Each is a seperate field, and each line has all four of these fields. So the body of my 1 page proposal has around 100 fields and if those are not enough I have a button two take you to the 2 page layout whixh has another approx. 100 fields.
This text suggests that you can probably define a related table for these fields where a row of fields in your current table becomes a single related record. It's possible to design a layout using that approach that can automatically adjust to any number of pages needed for a given proposal and you won't need two layouts to do so. But I am going by very partial information here.
An example of this approach can be seen if you look at the Invoices starter solution that comes with your copy of Filemaker. It can print 1, 2, however many, page invoices all from one layout.
I am using FIlemaker Pro 10, it does not have a invoice starter solution, but I think I know what you are refering to. If I create another table for invoice line items, how will thethe multi line descriptions show up in a search? Also I don't think you could see the entire description without having to scroll down. One more thing is how would you control the page break on a multi page proposal?
Thanks for the help,
Your questions are why I am suggesting you look at that starter solution. No scrolling is needed to see the line items on the report layout for the invoice. A portal to the line items is used for data entry, but not on the layout used for printing it out.
Here is a very simple, bare bones, Invoices demo file from another forum that also uses this method: http://fmforums.com/forum/showpost.php?post/309136/
As a short term solution, you may be able to take your two page layout and set sliding properties on the fields and any layout objects located in the body below them to "slide up" and "resize enclosing part". Then, when you print or preview the layout, the empty, unused fields in your layout will disappear.
Key facts about sliding layout objects:
- It's only visible in preview mode and when you print/save as PDF...
- Sliding fields will shrink but not expand.
- All layout objects below and in the same layout part as the slide/resize field need to also be set to slide up and resize.
- Objects in headers and footers will not slide.
- Portals will shrink/slide to fit the number of rows of records, but fields within the portal row will not shrink/slide.
- Fields will slide up only if Top alignment is specified for it and will slide left only if Left alignment is specified.
- Consistent side borders are difficult to achieve with sliding fields.
I looked at the starter solution in the link that you included. That is the type of setup that won't work. We do not have a set list of things that we sell. Every proposal is different. Some items in the proposal may take up several lines. If you go beyond the capacity of the line in the portal another line shows up, and you can continue typing, but when you look at it in browse mode you have to scroll to see all the lines. By having each line a field they are all always visisble. As far as I can tell there is no way to have a portal extend and make those lines always visible, something like text wrap.
That file is not a starter solution. It is a demo file created by Comment, a person formerly active in both that other forum and this one.
Please note that the issue you describe also exists with having separate fields on your layout. But with both, you have the options of setting up fields that are several lines of text in height that then, when printed or previewed, shrink down to just the size needed to display the text. This cannot be done with fields inside a portal, but if you take a closer look at that demo file, you'll find that it uses a portal for data entry, but does not use a portal for printing out the invoice and thus this issue is avoided.