What you want is called a "list-detail" view. There are a few different methods for creating one; you can search the forum for previous threads. (One of the more common is to use a portal for the list on a form view layout, just to give you an idea.)
You also might consider putting the "form" section in the footer of a list layout. You get the "list-detail" very easily that way.
Finds and so forth work just like they would in any other list, so you can leverage what FM does on its own. When you switch records in the list, FM will natively show the active record in the footer.
Essentially no scripting, no self-related portals, etc., but it does split your screen horizontally instead of vertically.
This may be a deal killer for you. I'm personally not sure why, but some developers and users only expect the split to be left/right. If that's the case for you, there are a lot of discussions and examples about that. For example: http://www.modularfilemaker.org/module/masterdetail-2-0/
Having done some consulting work in a past life with Siebel enterprise CRM, where top/bottom was (at the time, at least) a "normal" view, I find it quite comfortable, and I can get a a user used to it in about 20 words or less.
I'm (probably) biased, but where I'm going for "list-detail", I find this split much more flexible. IMHO, wider lists tend to be more meaningful and useful, and having the form able to "stretch" vertically might resize a few objects, but it doesn't make new elements fill in the vertical space. Where I'm wanting the objects in the form (mainly fields) to stretch (with anchoring), left-right is usually my main concern, anyway.
Should you wish to explore this option, I will point out one caveat that you can easily work around. In the footer, the tab order won't take you from one portal row to the next. You can, however, add an object to the end of the portal row, at the end of the tab order, with an onObjectEnter script trigger to take the user to the beginning of the row and then go down a row. (If you go "down" first, you'll trigger the next row's object. Obvious, once you've screwed it up like I have! )
One unanticipated advantage: If you shrink the window vertically, to where the footer won't fit, FM leaves off the footer and just shows you the list. Thus, on the desktop, you can effectively hide the form. The user can, of course, just stretch the window, so it's not a security tool or anything, but it's a nice way to focus the user on the list portion. We use this, for instance, when we want the user to click records to select them.
Siebel example (just to demonstrate that the top/bottom split isn't unprecedented):
FileMaker example (pardon the quick and sloppy privacy blackouts):
Could you elaborate? How does it help to have a single-record portal on the right? (I'm sure it does, I just don't understand.) Is this two portals, two TO's, a script trigger on the "global selector"?
Most of all, how is this
Re: "You also might consider putting the "form" section in the footer of a list layout."
? (The "Re" part, I mean?)
Sorry, keywords. I feel dense for asking. I'm just not making the connection, and I suspect I'm missing something that should be more obvious to me.
1. Top left is a global field in which to type. This field has a script trigger so that the field and its matching calc (see below)—and hence the relationship it drives—is updated with every keystroke (the script simply exits the field and then re-enters it).
It is used in a relationship to narrow down a list of names. The technique is to couple this field with a matching calc field that appends a z to field contents—if you type chr the calc will be chrz, etc. The relationship is set so that the global field has a ≤ match and the calc field has a ≥ match to the name field. This means that with every character you type, the list of matches reduces in the portal below. (Acknowledgments to Ray Cologon of NightWing for this technique.)
2. The left portal shows the reducing list as described above. The portal row is defined as a button which posts the contact ID from the selected row into a separate global field which drives the relationship used in the right hand portal.
3. This whole panel on the right is a portal with just one row, in which whatever detail fields you require from the related record can be displayed.
I use this technique for selecting all kinds of records—contacts, quotes, invoices, job cards, etc. etc.
I was wrong about the body part comparison though. In my case I use a Form view with no footer part.
Thanks for your answers! I am going to try the Master Detail version as it looks like it suits my needs completely :-)
Thanks for the clarification. I think I'm caught up now.
I guess my point was that, if the left/right orientation isn't critical (I know it is for some, but I personally don't see why), then you can achieve the same thing with a lot less scripting, no extra TO's, etc., in a top/bottom orientation. Along about FM 8, data entry was allowed in the header and footer parts. You couldn't before.
I remember seeing that in a DevCon preso (which wasn't at all about that, oddly) and rushing out of the room so I could test it. I abandoned the gymnastics of left/right list/form then, and I haven't looked back. It's way simpler, and the only downside is that for some reason people sometimes have a strong preference for left/right, and I've never really understood why.
If I'm working with related data anyway (like in a session model) then it doesn't really make a difference since I need portals anyhow, but if I'm on the layout of the list I'm showing...
Incidentally, we use the same form I showed (the one with the privacy blackouts) for selections, in a new window. We rename the window, which triggers the small variations (hide whens for OK/Cancel buttons, script parameters on the row click, etc.) for selection, and we also resize the window to only show the list. No additional "select" layouts, no copying/pasting/repointing. Plus, the user can do finds or add new records on the fly (given that the routine parameters don't disallow it).