Create a relationship, mostly likely a selfjoin (SJ) and/or cartesian. You'll use this for your scrollable list.
Create a Form layout. Create a portal in the upper part of the body. (You probably don't/ may not need the header or footer.) The portal will be based on your relationship, showing all relevant records. Add whichever fields you need, set to 'non-enter'.
Add a simple script to the row of the portal, so that clicking it 'takes' the user to the relevant detail record, ie GTRR (Go To Related Record).
Hi, Yahbai, and welcome.
There are multiple ways to do what you're trying to do. You can certainly do it with relationships and a portal.
The simplest method doesn't require either relationships or portals. Just base your layout on the user table and create a 'list' view. That will give you the scrolling list that you want.
Then enlarge the footer area of that layout and place your 'detail' fields (plus the buttons you need) in that footer.
Now, when you choose a row in the list, the fields in the footer will automatically populate with fields from the selected row.
btw, yahbai, the method I've suggested works because of the specifics of your requirement. It would serve you well in the bigger picture to also understand the portal-based method which has greater general applicability.
In that method, you can base your layout on any table. You use two relationships -- one relationship for the list, which you display using a portal (I'll call it the portal relationship). The second relationship to select a single record for the detail (I'll call it the detail relationship).
The first relationship -- the portal relationship -- can be structured to control which records appear in your list. You'll often base it on the primary key of the parent table (the one on which your layout is based) connecting to a child's foreign key. That gives you a list of records that belong to the parent. So, for example, you can use it to display a list of all employee records for the parent company record. However, you can structure it to select records in many different ways.
You'd then make each portal row a button that, when clicked, sets the ID of that child record into a global field. The global field is used to drive the second relationship -- the detail relationship -- and thus selects the clicked record for that second relationship.
Now you can place fields from that selected detail record onto your layout, so they are available for display and editing.
This second method is "more expensive" for performance potentially than the first method. I would pick the first one most of the time.
You might consider this approach using a popover. I did this and list view remains very fast since in my instance, I have summary fields on the popover as well as related data. It also means the data is transactional because the popover is modal.
Excellent suggestion, Charity, and thank you for guiding me to that demo file. (And LaRetta for creating it.)
Re performance on the portal/ scrollable list on the same layout as a data entry 'chunk', it's going to depend on your environment. I have that setup in one particular solution that was originally written in v9. It's now hosted on a v12 server and is just one of many solutions on that server. That particular solution has about 10 users, of whom half use it as their primary, all-day tool. Re data, the primary file has several hundred records (people) and the related file has, on a very rough average, five records per person (contracts). In this case, the Contracts table is viewed as the 'primary' one because that is the workflow requirement; the users find that style of layout very 'job friendly'. The portal displays other contracts that this person has done.
Thus, overall, pretty small record numbers. Performance is excellent but I'm guessing it might be crap with different record numbers.
All that said, now that v13 exists, the popover may well be much better architecture. (In our case, we're 'banned' from getting a v13 server indefinitely so can't go there just yet for that solution.)
thanks all for the replies. I got it sorted out in a rough way now, and will figure out a more extensible robust way later.
I'm sorry to everyone for not replying sooner....
...while I was figuring out this layout problem I stumbled into the whole fact that filemaker isn't (is? ...not sure what to say) transactional (ok I'm sure I'll get flamed for that).
I would like to use a traditional transactional approach in my design (it is multi user, it does store shop financial records that it would be best to explicitly control when/how/who/when commits or edits etc). I'm also doing a strictly webdirect solution where I'm hiding the FM menus/toolbars etc, so need to code my own save/cancel/edit/etc controls.
So now I've stumbled into that, ahh, unclear situation of what is the best way to make FM "transactional". Geists, Colibri, ...everyone seems to have a favourite technique).
I'm going to post a separate question asking about this - is there a "best" way to use FM in a transactional model? I hope it might get a simple answer (its really a simple question...), but at this stage I'm not exactly confident of that lol.
You guys got any thoughts on that?
Anyway, thanks again to everyone to helping with my question here!
I'd go with Todd Geist's model, he's been doing it for years without problems.