I used to use this method where you have two global and two unstored calc fields – say, cSortAsc and cSortDesc – with
gSortDirection = "asc" ;
gSortField = suchAndSuch ; thatField ;
gSortField = soAndSo ; otherField etc
and cSortDesc testing on "desc"; dates and numbers are brought into a padded text format to sort consistently
then using these fields in the portal sort order, sorting asc and desc, respectively. Attach a script to the column headers and pass either the new field name or (if same as active) switch the sort order.
Has the drawback that you need at least two fields per sorted portal in the table (rather than four, since nowadays you could substitute the globals with $$vars).
No idea how viable this is today (and augmenting it with modern tools; this is from the 7ish era), and of course I cannot judge how easy you find this to implement …
Kevin Frank pointed me in the right direction; adding a couple of fields to each child table that gets sorted and using them to sort the portal on. Works fine for portals that have no more than a couple hundred records. After that it bogs down.
why ask questions here if you ignore the responses?
Who said I ignored the responses? I stated that Kevin Frank was able to help me with my problem.
I'm not going to get into a war of words, but I found your response inappropriate. End of discussion.
If the solution that erolst posted was "inappropriate", what solution did you end up using? I'm trying to figure out the best way to do this too....
I was looking for a solution to a similar problem, and stumbled across this posting by Tom Fitch: Fitch: FileMaker Portal Sorting That Doesn’t Suck
I found it very easy to implement - but it does require a new field, perhaps two...I ended up using 3.
I made one field for the "ListOfIDs..." summary; a global field to hold that list; and the calculation field that determines the sort order for each record (based on the global field's list of IDs). I haven't tested it with a large set of records, but seems to work really well so far. You could use a second "ListOf..." summary field to compile a list of the actual sort orders so you could pass it to the server for context recreation, or just compile both the IDs and the sort order via ESQL to pass both.
Just to keep this post up to date, since it's first in Google for the subject. Here is Kevin's latest post on the matter of dynamic portal sorting & filtering, courtesy of Joel Englander genius, hits the high performance challenge and suitably beasts it!
1 of 1 people found this helpful
I'm partial to the technique of using multiple portals hidden under different slide control areas. Clicking on a column header to sort simply uses Go to Object to switch to different panes. Very easy to setup. The slide control can easily be hidden so it doesn't appear to be there. The downside is when needing to make a change to the portal requires the same change across all iterations of the portal.
I'm partial to not allowing sorting!! haha
I liked the multiple portals approach, until that one fateful day I found myself trying to update 45 portals. Now, I will fully admit, that the requirements for the sorting in that use-case should have moved me to redesign the layout/workflow. But it was a long time ago, and I didn't know any better.
There are also a lot of cases where I need to allow sorting on multiple columns. In most cases, I prefer to design around a list view instead of a portal. It can't always happen that way, but I'm creative!!
Well, yes, of course. Excessive # of rows and one should use List View for the related records. A portal is great - using Sorting and/or Filtering, but within reason.
::mischievous smirk:: "within reason" That's subjective. When have you known me to be "reasonable". haha