paul at researchware.com
Wed Sep 18 11:09:06 EDT 2019
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
> thing to do in this case) then I'd still recommend abstracting to a
> 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
> case "descending"
> sort xList international descending
> 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
> 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,
> P.S. Indeed you might find that not all your 'sort text' instances are
> 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.
More information about the use-livecode