I don't understand why a list view with container fields in the body won't work.
You are right; I tried it again this morning and it does work; I don't know what I did wrong the first time I tried it but now it works just like how I wanted it to.
Phil: I got the photos in my container fields to render in list mode as you suggested. However, the photos for all records appear as one scrolls down the window, not just the active record. Do you know an easy way to just show the active record's container fields yet still allow "next" and "previous" navigation of records themselves?
The details can very a bit depending on your table and layout design option.
The Extremely general answer:
Put next and prev buttons on your layout.
Write scripts that manipulate either found sets and/or relationships to control what the user sees.
attach them to the buttons
Exactly how you implement this depends on your layout and table structure.
You apparently have a parent table which contains your "active" record and a second table that stores the images in container fields that make up your list. I'm not sure if you are describing a standard list view layout displaying fields from both tables or if you are using a portal to display your container fields.
From your first post, I'm guessing that you chose the first option.
Let's call your parent table PARENT and your second table IMAGES.
Let's assume you have a single field in PARENT that uniquely identifies what group of images you want the user to see, called Parent_ID. This field should be the Key field linking PARENT to IMAGES in your relationship between the two tables. I'll treat it as a serial number, but it could be a text field of unique names or even a date field and the method can still be used.
Define a global number field, gParent_ID (It should be the same data type as Parent_ID).
You'll need to give gParent_ID a value when the user first views your list layout. You can set the value to match Parent_ID of first record or you can put in place some method of asking the user to select a record.
Your next script would look like this:
Set Field [PARENT::gParent_ID, PARENT::gParent_ID + 1]
Enter Find Mode
Set Field [PARENT:: Parent_ID, PARENT::gParent_ID]
Set Error Capture [On]
Set Error Capture [Off]
# Add a sort step here if the order of your images is important
Your previous script is identical but it subtracts one from gParent_ID instead of adding one.
When your user clicks the Previous and next buttons you step through your PARENT table's records one ID number at a time, while bringing up your matching set of related IMAGE records. Note that if these script produce a value for Parent_ID that does not exist, the user will get an empty set of records and a largely blank screen. You can add additional details to the above script example to prevent searching past the limits of your table and to skip nonexistent ID values.
If I've made some wrong assumptions about your layout and table design that don't match what you are doing, let me know.