It's not clear to me why you need a different portal for each test if this info is all being recorded in the same Tests table. Or do you have one table of tests for each type of test that might be performed?
When I look at your screen shot, it's not immediately obvious that you have any portals on that layout...
If you have a single tests table, it might be much simpler to set up a summary report based on tests that includes fields from Test reports. You can pull up a found set of tests records for a single test report on such a layout and sort your records to group them by individual test. Data specific to each test can be put in a sub summary layout part with details from each tests record grouped under that sub summary layout sub heading.
The reason I have a Test Reports table (which has basic info on the equipment) and a table for each kind of test is because some tests could have 30-40 fields and having a single table to cover all fields would result in a table with hundreds of fields - many not being used depending on the type of equipment. Doing it this way keeps the user only creating related records in child tables if they actually have test data to enter.
All of those enclosing boxes around the tests are the borders to the portal. I'm defining the portals to show just 1 record (that's all there would be anyways).
What's happening is if one of the portals/tests are hidden due to no data being entered, the others will slide up (that's what I want). However, sometimes the slides result in the portal/test being cut up between 2 pages. I'll attach another screen show to show that.
The second half to that image/report
Hoping that makes sense. Just looking for a way to ensure that sliding doesn't cut off any objects between 2 pages
Well I didn't suggest that you shouldn't have multiple tables for your tests. I just asked for clarification as to whether or not this was the case or not. I then described a possible approach if you had a single tests table.
All of those enclosing boxes around the tests are the borders to the portal.
But if your portal is set to display only one related record, you don't need the portal, just the fields from the related table unless the portal is filtered in order to show the correct record.
What I saw on your first layout only showed single records in what might or might not be portals. That doesn't mean that your portals are "wrong" or won't work, it's just an unneeded complication in your layout design.
What I am looking for is a way to be able to make sure that when they slide, they only slide if the entire portal object can fit on the page and if it can't, then it will start a new page.
You can't selectively turn sliding on and off. So you may have to go the extra 50 miles and create several different versions of this layout and set up a script that selects the layout that is the best "fit" for a given combination of specified tests.
Understood. Thanks for the heads up about the portals - kinda forgot that I was being redundant with those as yes, in about 99% of the reports I'm making, there should only be 1 child record from each portal.
The only reason I had to do portals in one of the layouts is that for a specific piece of equipment, you do the same type of test 3 times but on different parts of the equipment. Rather than make 3 separate tables (for each occurrence of the test), I have my portals set up so that for each portal object in the layout; portal 1 only shows line 1, the second only shows line 2 and the third only shows line 3.
One question I have about that is while I have nothing built in for the user to re-sort the portal values of that test, am I in danger of potentially having the wrong information show should a user (or admin) go in an perform a sort of those values at some point? Hopefully I'm making sense with that one. Basically, If portal 1 enters data into portal line 1, portal 2 enters data into line 2 and portal 3, line 3, is there any danger of line 3 showing up in portal 1, line 2 showing up in portal 3 or some permutation of that?
As for the print layout, I figured the 50 miles might be the answer. It's not THE answer I want, but it's AN answer . I may just skip the section/portal hiding and just create a static report for this one.
Re-sorting records in a portal is not a built in feature. You cannot re-sort the values shown in a portal unless you go to a good deal of trouble to specifically design and script to add that capability.
Oh good, then I'm not in danger of that happening even if as an admin, I were to sort those same records in a totally different layout (such as an admin only table layout that lets me see all records and all fields)?
You can only sort record from the layout's found set, not the related records shown in a portal. Related records can only be sorted to a static specified sort order chosen in either portal setup or for the underlying relationship.
Methods that sort portals "on the fly" have to work around this limitation--either by displaying different copies of the same basic portal each with a different specified sort order or by manipulating values referenced by a complex calculation field that is specified as the field in the portal's sort order.
Either way, that's not something that's likely to happen by accident.
As always, a great help. Thanks Phil!