I am just beginning to re-learn the basics of interface elements and layouts after years of not looking at our favorite database application.
Presently I am creating a fairly simple application to keep track of items for an enthusiast. i envision somewhere between thirty and one hundred records, using two basic layouts: a list of items, and individual records.
The list view only admits one column, which is not an efficient use of space; requiring excessive scrolling and does not permit viewing enough entries at once. So…
Can I use multiple portals on the same layout page? It occurs to me that each portal could display a subset of the total list? Perhaps filtered by alphabetical range of the first word in the record name:
Short answer is yes, you can display multiple portals on a layout.
You can also display multiple columns in a list view. Columns, here, refer to fields.
Perhaps you are referring to columns of records. This can be done in preview mode, not in browse more. I could see here why you would want to use portals instead of list view.
That said, there are multiple ways to skin this cat. As an example, think of the Music or Contacts apps on the iPhone. A sidebar shows the letters of the alphabet. These act as shortcuts to navigate to songs / contacts starting with the character. The same could be done in FileMaker (in the header).
Yes, I want a list of record names that can be clicked on to change to the individual record layout view. Only one column (field) for each record. I have looked at a number of forum discussions of how to display multiple columns of the same list in FM and none of them seem to fit either my idea or my skill level....
What platform are you designing UI for? There's a world of difference between iOS, web, and desktop. And iOS can be split into small format and large format. Native OS behaviours, and window space, need to be considered. For example, on a desktop you pecking behaviour (point and click) is dominant. On iOS, swiping is normal, and provides great functionality. Behind the scenes those behaviours need different layout configurations.
I think it gets trickier when you want to have Parent->Child->GrandChild. As I recall, you have to carry along another key for this final Grandchild to work as expected. Haven't tried this in a while so maybe it's better now.
Portal behavior that you aspire to perform, is a common - and somewhat unique - method in FileMaker...... although this construct may not be the right one for you use case, as others have noted. There are many other ways to get to the end result you are looking for, but here is how you would use multiple portals, each filtered by a alpha subset of data.
Each portal would be based on a different child Table OCCURRENCE (Alias), albeit it the same table.
On the parent side, a global field would be used for the relationship - and here is where some FileMaker unique magic can occur. FileMaker supports multi-line predicates. What this translates to in layman's terms, is a single field can contain a list of values separated by a carriage return (&¶&) and any records on the child side of the relationship that match any of the values in the list, are the filtered records that would show on the portal based on that related table.
So let's say you have a calculated field in the child table that takes the first character of the items.
Using a SET FIELD, set the parent global to "A" &¶& "B" &¶& "C" &¶& ..... through J.
Using that global as the parent side of the relationship to the calculated alpha field in the child table, would result in a table occurrence only showing those records whose alpha character is A thru J.
You could have a single child portal, and with a button, reset the parent global to a different subset of the alpha characters, resulting in a different filtered list in the portal.
The List-Detail method that @bdbd suggested, might be a far better approach. The portal is based on the same context as the layout, and any action (say a FIND) against the layout, will reflect in showing the resultant FOUND SET in the portal. Clicking on any row, selects the record, which can then show the other fields in the table, say, to the right.
