A "second layout" can refer directly to the same table as the first and then there would be no need to pass any data to a different table. (You don't pass data to layouts.)
You need to let us know what TABLES are involved here and if there are any relationships linking them.
Please note that your examples on the two layouts are sufficiently abstract that I am unable to picture exactly what you are trying to do with your check boxes here. And example with real values and real field names will be easier to understand here.
Maybe I'm taking the wrong approach but here are a couple of screenshots (combined in one jpeg). On the left is the main layout and on the right is the form I will eventually print with the required information. The specs I want to include in the form are the ones with the "yes" selected in the last column on the left layout. Does this help? If there is an alternative solution i'm open to suggestions.
I did warn you that it's the tables that matter here, not so much the layouts.
What I see here suggests that you may (or may not) have a very serious structural issue.
Is each row of data on the left a different record shown in list view? Or is this a form view of a single record?
If it's a form view of a single record, I strongly recommend that you redesign the structure of your database.
What you should have are several tables with relationships such as:
Customers::__pkCustomerID = JobSpecs::_fkCustomerID
JobSpecs::__pkJobID = InkUsed::_fkJobID
If the above format is unfamiliar to you and you can't fully understand it, see this link: Common Forum Relationship and Field Notations Explained
The Left hand layout would be a single record based on JobSpecs with a portal to InkUsed that would list rows 1-8 (and can now list any number of inks for a given job, you are no longer limited to a max of 8.) The right hand layout can be based on either JobSpecs or InkUsed. If you base it on JobSpecs, you can use the same portal to InkUsed as on the left hand layout, but with a portal filter specified:
InkUsed::SampleReq = "Yes"
or you can base the layout on InkUsed and perform a find for a specific Job with "Yes" entered in the SampleReq field as additional find criteria.
In either case, you can include fields from Customers as well as JobSpecs to fill in the info shown on the top of the second layout.
I've finally gotten around to taking your advice and making the ink info a separate table with a link. However, i have a couple hundred records using the original method. Is there any way to map the old fields to new fields in a different table?
I've figured it out.
1. I created a number field and assigned 1-8 for each line of the original colour info.
2. Ran a script to create 8 records in the portal for each line of colours.
3. Exported the original field values along with the OrderID.
4. Imported to the new "Colours" table matching OrderID and Colour Number (1-8).
5. Repeat import for each Colour Number separately.
Worked like a charm!