When I implemented it on one of our solutions, I was getting some screen flicker. Tweaking the GTRR to open in a new window at -1000 from the top and then closing that window when I was done eliminated it completely.

Thanks Again!

Combining the techniques allowed an insanely “fun” user interaction experience and instant UI responsiveness in a client / server environment without any lag and no extra overhead on the server as well.

The direction these techniques are taking is really allowing developers to build entirely new experiences never imagined possible in FileMaker. Too much fun! :)

Thanks for getting the word out as well as keeping the conversation and ideas flowing.

Thanks for pointing out that this technique is multi-user friendly, I should have mentioned that in the article.

I don’t recall the details but thought I saw concern in someone’s post about using this technique in multi-user environments. This is not a problem if the portalSort calc is unstored and dependent on a global [or other unstored result like FoundList( )].

@Rob and @Heather, I would encourage anyone to modify the calc in a way that seems most clear. I've seen a number of variations. In fact, I was going to include a "flattened" version of my calc in my original post but edited it out for simplicity. Here it is:

ValueCount ( Left ( ¶ & $$gIDs & ¶ ; Position ( ¶ & $$gIDs & ¶ ; ¶ & ID ; 1; 1 ) ) )

Darren Terry and Chis Manton both pointed me to Sander Selover's custom function, which strikes me as very clean and readable:

Let ( [
v = ¶ & _listOfValues & ¶ ;
p = Position ( v ; ¶ & _value & ¶ ; 1 ; 1 )
] ;

ValueCount ( Left ( v ; p ) )
)

(Notice I'm not using quotation marks around the paragraph symbols, it's not required and it's more readable, I think, without them.)

I would not expect such variations to impact the performance, and whether you put the calc into a custom function is again, really just a matter of taste and/or your organization's coding conventions.

@Heather I really appreciate your taking the time to post the FoundList custom function, but I have to tell you it does not perform well at all on large set of records. It was really noticeable on anything over a few hundred child records.

But again, for smaller related sets it's not going to make a perceptible difference, so if you prefer to put your logic in a custom function there's no reason not to. My preference these days is to put my logic into scripts, all else being equal.

For best performance in my example file:

1. - the child layout should be in form view
2. - the child layout should have no fields on it
3. - the script should freeze window before the loop

Replace your current portalSort calc with the following to determine each record’s post-sort position:
valPos ( FoundList ( Child::ID ; 1 ); Child::ID )

The following custom functions will allow you to remove the ID-building loop entirely.

FoundList ( field; start )
// start should always be set to 1
GetNthRecord ( field ; start ) &
Case( start < Get ( FoundCount );
"¶" & FoundList ( field; start + 1 )
) &
Case( start = Get ( FoundCount ); "¶")

valPos ( array ; value )
PatternCount ( Left ( "¶" & array; Position ( "¶" & array; "¶" & value & "¶"; 1; 1)); "¶")

Example: valPos ( FoundList ( Child::ID ; 1 ); Child::ID )

My personal approach. I’ve made this into a custom calc so that I can determine the index value for a selected item in any given list of separated values like a value list.

Let
(
[
items = $$gIDs ;
items = If ( Right (items ; 1 ) "¶" ; items & "¶" ; items )
];
ValueCount (
Left (
items ;
Position ( items ; ID ; 1; 1 ) + Length ( ID )
)
)
)

I’ve tried both of the other techniques and have found the “dynamic-portal-sorting” method to be too slow over a network, and the “hidden tab element/hidden-sorted-portals” technique is a lot of work (compounded when you want to add another sort field).

Thank you so very much for sharing this new technique and the demo file! Very clever! I look forward to implementing the “Fitch Portal Sorting Technique™” immediately! :D

P.S. Thanks also for the new (to me) term, “technical debt”. I will be having less of that now. ;)

I am a bit concerned about the performance with a lot of records, but then again, sorting a lot of child records is never fun, even when FM does it itself.

It will definitely be usefull for me, thx again.