Yes I totally agree about this one.
I agree, this would be a nice feature...
You can accomplish a form of Dynamic Portal Sorting by adding 2 fields to the related table...
This is a very simplified explanation...
A global field, example "_g_Sort" and a Calc field "_c_Sort" with the formula... Evaluate ( _g_Sort ) ...
Then use a script to set the _g_Sort field to the name of the field you want to sort by...
Set the Portal Sort option to include the "_c_Sort field"
You can expand on this concept to include Ascending/Descend via a second calc field. And you can set entire strings in the global to be evaluated for more complex or layered sorts.
+1 for this. It's amazing something so trivial still isn't in the product.
I feel your pain on this one but it is a case of wanting a specific feature without working out all the rammifications it would create. By doing this you would in effect create a whole new class of object in FMP. A column headder. These days we just use a simple text object as a column headder. The more "open" FMP remains the more powerful it is. When you start narrowing the functionality of some things all it really does is take away your freedom as a developer. As pinted out by wsvp, there are ways to accomplish this that allow for much more creativity and power that may not be possible if you are locked into a built in system of column sorting. You can make an argument to have both ways but that would likely complicate things. Good luck.
Think about where FileMaker currently allows you to click column headings to sort: table view. Are we talking about embedding a table view in a (form view) layout? This would be fantastic, but not trivial by any means.
If we're talking about a less drastic change, I don't think we necessarily need a column header object. What I picture is a script step, "Sort Portal" that would work essentially like Sort (which I'd love to see improved but that's another topic). And it would then be useful to have Get(PortalSortState). This seems do-able, although there are potentially tricky details such as how it would interact with the existing portal sort option.
Also, the ability to have a portal default to most recently created on top without having to sort and thereby force FileMaker to pull the entire related set of records over the network. It is more likely that a user will want to see the latest records on top (rather than having to scroll) than the records from years ago (the default).
The DEFAULT when you create a portal is Unsorted, as it should be; unsorted order is creation order, hence most recent records go to the bottom. You can easily reverse this by configuring the portal to your chosen sort order.
For a portal, the default is the sort order of its relationship.
@Tony, I don't see the default sort changing, but I could envision offering a default/scriptable portal scroll position -- that would be cool. (And I thought there'd been some tuning in recent versions of the number of related records pulled down at once, but I could be wrong.)
We know how to:
1. Sort a relationship
2. Sort a portal
3. Do neither (no sort) in which case the records will display in creation order, with the latest at the bottom.
My understanding is that:
1. Sorting a relationship causes all the related records to be pulled from the server to the client.
2. Sorting a portal causes all the related records to be pulled from the server to the client.
Therefore 1 and 2 are "expensive"
Let us look at 3, which does not have the same cost as 1 and 2
Let say we have a portal that displays 25 records and I have 45 related record.
Will I see the latest records on the screen by default or will I have to scroll? (No)
What records am I more likely to want to see...the most recent or the ones from the past? (survey says most recent)
Solution: Checkbox option to pull and display the latest 25 records (not saying that it would be easy, or even possible...just useful for a better, less expensive user interface)