Good to know. Thank you.
On 9/18/2019 11:03 AM, Mark Waddingham via use-livecode wrote:
On 2019-09-18 15:43, Paul Dupuis via use-livecode wrote:
Again, thank you Mark - this helped immensely.
In making a commercial text analytics application, we do a lot of
sorting of user entered textual data. With the move from LC6.7.11 to
LC9.0.5rc1 we discovered the sort text issue bug, but them we many
dozens of sort statements through out our code, we wanted to be sure
switching all text sorts to international was the right way to go. All
are for user facing data. The alternative was to abstract them to a
new function that used any of the work-arounds you identified for the
sort text issue.
If you are updating to use sort international (which sounds like the
correct
thing to do in this case) then I'd still recommend abstracting to a
command
handler which does the sorting (which will have no measurable impact on
performance). e.g.
command sortTextListForUserDisplay @xList, pDirection
switch pDirection
case "ascending"
sort xList international ascending
break
case "descending"
sort xList international descending
break
end switch
end sortTextListForUserDisplay
The reason here is that it means it gives you more control in the
future. Whilst
it didn't make it into 9.5, we have been working on more general
'collation'
support which allows you to choose (with a high degree of flexibility)
how sorting
occurs. So if you abstract now, then it makes it easier to change
things in the
future should you want to.
Warmest Regards,
Mark.
P.S. Indeed you might find that not all your 'sort text' instances are
suitable
for sort international when you go through - so abstracting those with
a similarly
richly named handler might also help code documentation as much as
anything else.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
