> Thanks for working on it. What is it using instead of sortOn?
Array.sort(compareFunction)
> BTW, the build failed some sort tests. See a recent set of results.
thanks for the heads up. Some are fixed, and some I'm now struggling
to debug (more details in the thread called "git commit: [flex-sd
On 6/21/15, 2:18 PM, "Mihai Chira" wrote:
>This is now done (pending some unit tests) - see recent commits.
>
>Could someone please test that they can correctly sort an mx DataGrid
>by clicking on its columns in an MX-only project? For some reason when
>I try in IntelliJ I get this error[1]. An
This is now done (pending some unit tests) - see recent commits.
Could someone please test that they can correctly sort an mx DataGrid
by clicking on its columns in an MX-only project? For some reason when
I try in IntelliJ I get this error[1]. And if you could try the same
for a Spark-only projec
That's very useful Peter, many thanks!
It looks like I can use the framework.swc for the common part of these
classes. Will get round to it later this week, I hope.
On 10 June 2015 at 14:26, Peter Ginneberge wrote:
>
> I had a quick look yesterday and when I toggled "mx only" vs "spark only"
> I
I had a quick look yesterday and when I toggled "mx only" vs "spark only" I
saw the mx.swc swapped for the spark.swc. A sparkskins.swc is added for "spark
only" while there is no equivalent for "mx only".
For AIR projects a sparkair.swc is also added, there is again no mx equivalent.
Both co
Great points, thanks all.
Does anyone know how I can check which swcs are included in mx-only
projects and which in spark-only projects, so I can see where I can put the
common functionality if that's the route I / we'll choose? Thanks.
On 10 June 2015 at 12:40, Kessler CTR Mark J
wrote:
> Issu
Issues I see or agree with.
-MX only or Spark only projects.
-Inheritance of these classes / child classes.
-Possible different behavior.
-Mark
On 6/9/15, 3:29 PM, "Peter Ginneberge" wrote:
>
>I don't know which classes end up in which swc, but the same rule may
>apply
>for Spark only projects in which case Spark classes extending mx ones may
>be a
>no no as well.
Good point. In this case the mx Sort and Sort field are already in t
I don't know which classes end up in which swc, but the same rule may apply
for Spark only projects in which case Spark classes extending mx ones may be a
no no as well.
regards,
Peter
On 9 June 2015 at 15:35, Alex Harui wrote:
Peter is correct that you want to be careful about having
HI,
Off the top of my head (and it’s been a while since I’ve looked at the code so
could be wrong) the spark class used the new i18n support in the FP so sorting
in non en_US locales may give you different results in MX than spark. You may
want to be be careful there as it may introduce subtle
Yep, good point, Peter.
I'll try that, Alex (making spark extend mx), I'll see how it goes.
On 9 June 2015 at 15:35, Alex Harui wrote:
> Peter is correct that you want to be careful about having mx-only classes
> depend on Spark classes.
>
> And in the strictest sense, I suppose there is a chanc
Peter is correct that you want to be careful about having mx-only classes
depend on Spark classes.
And in the strictest sense, I suppose there is a chance that someone’s app
depends on a difference in behavior between ObjectUtil and
String.localeCompare, although I personally don’t think there is
This may affect mx only projects (in FB at least) where spark related swc's
are removed when selecting "mx only" as the project's component set.
On 9/06/2015 13:33, Mihai Chira wrote:
I'm making lots of changes to SortField and Sort, and I'm realising
that having two versions of these files
I'm making lots of changes to SortField and Sort, and I'm realising
that having two versions of these files is error prone and duplicates
effort. From what I can see, the differences are:
Between mx.collections.SortField and spark.collections.SortField:
1. lots of asdocs changes
2. spark version i
14 matches
Mail list logo
