Describe the underlying data modeling for your four layouts. What tables are they based on? How are they related to each other? What kind of found set do you need to pull up for each of your lists?
It may not be possible to eliminate the page breaks without a lot of effort, but there's no way to know without a clear understanding of the data you have to work with for your report.
The form is based on a table called employee. Two of the lists are based on a table called Projects (each one is filtered for a different type of project), and the other list is based on a table called Feedback. Each project and each piece of feedback is linked to a single employee.
My final goal is to create a consice printable form for each employee. The first part of the form is general information on the employee, and then the lists summarize the employee's work on projects and manager feedback on the employee.
Also, I might be able to get a copy of Advanced if creating a built in function could solve my problem. I've been wanting to get a copy but I haven't had an excuse.
Ok, the first several parts are quite doable, the last part represents a challenge.
Base your layout on Projects. Use a Header or Leading Grand Summary for your "form" and make sure that you have a relationship that correctly links to the desired Employee Record.
Two of the lists are based on a table called Projects (each one is filtered for a different type of project)
Put these in the body of your layout and Add a "print above" sub summary layout part "when sorted by" your project type field. You can then find both types of project records and sort them by Project Type in order to get your two lists of projects. You can use the sub summary layout part as a place to put a "sub header for each group of project records.
The challenge will be including the FeedBack portion of your report. Each of the following options have trade offs so you'll need to pick and choose the best option for your report and your data:
1) Make this a separate layout and accept the fact that you'll have a page break between it and the rest of your report.
2) Use a Portal (or large ExecuteSQL field) to your FeedBack table. IF the feedback records are not the ones that need the individual fields to slide, this option may work quite well.
3) (This one's complicated) add a tempory "report" table to your database and base your report layout on it. Import both your Project and your feedback records into this table. Immediately after importing the feedback records use Replace Field Contents to give them a "Project Type" that is both different from any actual project types and that sorts last in your sort order. Now the sub summary layout part I've already described can work to give you all three lists of records. What can get really messy here is figuring out how to pull completely different data from two tables into a single table. In some cases, you may be able to use the same field for similar data from both tables and in other cases you have two sets of fields, one set for each table and you put all the fields in the body setting them to slide up and resize to close up the unused space. Often this can require field labels that are also calculation fields that are empty for records from one table and display text for records from the other table so that they also can disappear for a given record if the label is not appropriate to that record.
Unfortunately, #2 won't work. I suppose I could give #3 a try. The fields are pretty different between the two tables, but I might be able to find some common ground.
I don't know much about FileMaker Pro Advanced. If I got that would I possibly be able to make a custom function that does what I want? I'm not looking for how to do it, just whether it might be feasible.
Filemaker Advanced is well worth the extra dollars, but it won't help you any with this particular issue. Finding fields that can work with both tables may simplify things but they aren't absolutely necessary for option #3. The result can be a very complex layout that only looks correct when previewed/printed, but it is an option that can be made to work.
Thanks for the help. I'm hesitant to use #3 because other people work with this database and sometimes try to edit layouts, and so I want to try the least convoluted solution possible. I think I am going to try using #2, but I will base the report on feedback rather than projects, because I think that putting a portal for each type of project may work well, as the entries for each project are rather short.
This worked well, but I have one major problem now. There are employees without projects or feedback, but I still want to be able to generate this form for them. I guess I could create a dummy project for every employee, but that seems like a messy solution.
I think the insistance on no page breaks will make this somewhat "messy" no matter which option you ultimately use.
I'm still open to suggestions, but I think the approach I'm going to take is have two different layouts, one with the projects and feedback based on the Feedback table, and one without the projects and feedback based on the Employee table, and the script to generate the report will use the latter if no projects or feedback exist.
Except for the fact that there are employees omitted, the layout with projects and feedback looks relatively nice.