Building the interface is certainly possible - not entirely easy, but possible. Perhaps the harder part would be performing the sort. Unfortunately, FM does not provide access to the calc engine in either of the sort script steps (as they do in the 'Set Field by Name' script step). You would need to hard-code every possible field and sort-direction combination that the user might specify. Possible, but not easy.
One potential way arround this <cough> oversight </cough> by FM would be to display the data to the user via a Virtual List, where the VL was built via an ExecuteSQL step becaue here the sort could be scripted.
Also, a gentleman name Tom Fitch has devised a clever way of dynamically sorting a portal that involved a virtual list. There may be fodder in his blog article that would move your idea forward. FileMaker Portal Sorting Redux
I would LOVE to hear input from the FM Gurus on this issue. They probably have a clever solution that has never occurred to me.
Just my $0.02 worth.
1 of 1 people found this helpful
I have done something similar but in a simplified manner for one of my solutions: created a duplicate layout and turned each of the fields into a button which sorts the current found set on that field, and returns them to the main/matching layout with normal field access.
If the user wants to sort on more than one field in the sort order, then they have to confront the sort-dialog box and list of fields.
Editing the field list order to a custom order in the Define Database>Fields list provided a way to control the order in which the fields were listed in the Sort Dialogue, so a bit of design planning simplified the list of fields the users saw, though not actually hiding the fields farther down the field list as they scrolled.
isn't the sort "layout dependant"? When I sort on a field-limited layout and then switch to real layout (same table/T.O.) the sort is NOT retained.
I just tested this in FMP13 and found the sort order was retained between layouts of the same TO. It is Window dependant, but it's worked that way since I built the first version of my test file back in FMP3.
If it's not working, check for
- script triggers,
- same TO,
- no GTRR involved, and
- no new window.
When I performed a sort in one layout on a found set to force it out of creation order, and then used the layout menu to switch layouts to another based on the same TO, the new sorted order was retained between layout views.
Ah! not scripted Go To Layout, I see. Thanks for the clarification.
I've also tested this with a simple script which uses only the Go To Layout script step, and, unless I script something to change the sort order, the Sort Order persists even between scripted layout changes as long as they are in the same window and based on the same TO layouts.
What would you say the main difference is between:
(A) what you envsion &
(B) what happens when you hit the "Sort" button on the standard Status Toolbar on a layout containing only the fields you want to expose to the end user?
This might work. Let me test it a bit. Thanks for the idea.
Is there any way to do this with a second window but still using same table?
1 of 1 people found this helpful
When you create a new window the initial default position is that the new window will exactly mirror the existing one—same, layout, same found set, same sort order. From that point on, anything you do in one window will not affect the state of the other window. In fact, that is the whole point—you can have two (or more) windows open at the same time and see different views.
I think I now have a solution that works. I built a layout (“Sorter”) with only the fields that I want to allow a user to sort on. Then I have button from the main layout (“Main”) that runs a sort script:
Allow User Abort (Off)
Go To Layout (Sorter”)
Sort Records 
Go To Layout (“Main”)
This allows the user to sort the records only using the fields I expose on Sorter.
It seems to work.
Thank you ALL!
That method does make sorting by your intended fields the easiest and most obvious choice for the user.
But it doesn't prevent them from sorting by other fields if they choose to.
The user would have to know enough to explore the popup in the sort dialog though.
I agree and it is a big downside. But I do not see any other way around it. FileMaker needs to give developers better tools to get at the Sort function.
Why is it a downside? You gave them the easy way. If they want to use another sort - what is the problem?