On Dec 31, 2014 3:30 PM, "Harbs" wrote:
>
> I think the width and height are set by the skin, and the host component
size is inferred from that.
The failing tests are setting the BI's width and height, which does not
seem to propagate to the skin, at least in the test.
>
> See Skin.as explicit m
flex-sdk_release-candidate - Build #53 - Successful
Changes since last build:
[bigosmallm] fixes one more mustella test
For more information, check the console output at
http://apacheflexbuild.cloudapp.net:8080/job/flex-sdk_release-candidate/53/.
I think the width and height are set by the skin, and the host component size
is inferred from that.
See Skin.as explicit min and max values and SkinableComponent.measure()
Also, updateDisplayList() in SkinnableComponent calls setActualSize() on the
skin.
Does that help?
On Jan 1, 2015, at 1:
I am seeing that in the updateDisplayList() method of my BusyIndicator
skin, the unscaledWidth and unscaledHeight are showing up as 0. Even
hostComponent.width and hostComponent.height show up as 0.
But hostComponent.$height and hostComponent.$width show the correct values.
It looks like I migh
I hacked together a solution for this. I’m not sure if there’s a nicer way to
do it. Feel free to fix it up...
After my last commit, we are down to 20 ignored tests total.
It would be great if someone could check the one test that’s failing on the CI
server. It’s passing on my machine, so I’m n
The other set of failing Mustella tests are for ActionBar. Almost all of
the failures (except for 4) are sub-pixel failures. Should I just recreate
the baselines for these ones? Not sure how else to fix this.
Thanks,
Om
On Wed, Dec 31, 2014 at 12:52 PM, OmPrakash Muppirala
wrote:
> Here is s
Piotr, I have a question:
I’m looking at the EventOverrideTest.
The old tests look like they were run via xml like this:
true
false
empty.xml
false
false
These values were different for the different test cases.
How is TestData.overrideEditManager suppo
Could someone take a look at AllParaAttributeTest? It’s passing on my local
machine, but failing on the ci server. I’m not sure what’s going wrong there.
If we can get that test to consistently pass that would be nice…
On Dec 31, 2014, at 12:36 AM, piotrz wrote:
> Harbs,
>
> Congratulations!
Here is some information on the failing tests:
BusyIndicator:
[java]
mobile/components/BusyIndicator/integration/BusyIndicator_Integration_tester
BI_weak_ref_test Failed AssertPropertyValue(body:step 1) bi02.isInMemory
true != false
The BusyIndicator used to be a component with the visuals
> Could this be improved to have a better interface?
Darrell, don't -error-problems, -warning-problems, and -ignore-problems allow
the problems to be specified either by fully-qualified class name or by numeric
problem code? And isn't the numeric problem code displayed along with the
problem
No problem. It was not obvious, and I don’t think I’ve ever seen that
pattern before. That’s why I’m hoping you or Gordon know how to teach the
parser or reducer and other code how to handle this. It looks like the
compiler sees the {} as a block and not an object literal.
-Alex
On 12/31/14, 5
Agreed I see it now. Sorry for the bad info.
-Darrell
On Wednesday, December 31, 2014, Alex Harui wrote:
> Yeah, I had to read it twice, but I believe result is supposed to be
> assigned to an Object with a property called “get” that points to a
> function. The {} after result is an Object lit
Lol, thanks.
-Mark
-Original Message-
From: Erik de Bruin [mailto:e...@ixsoftware.nl]
Sent: Wednesday, December 31, 2014 7:47 AM
To: dev@flex.apache.org
Subject: Re: git commit: [flex-sdk] [refs/heads/develop] - FLEX-34710:
s:DataGrid doubleClickMode was throwing an error when assigned
It is on my ToDo; I'll give Mustella a bit more chance to object, but
I think it's too busy with the FXG/mobile failures ;-)
Thanks,
EdB
On Wed, Dec 31, 2014 at 12:00 PM, Kessler CTR Mark J
wrote:
> Erik,
> Is it alright if I cherry pick this commit to the RC. Corrects a RTE for
> the s
Lovely Email! <3 :)
Piotr
-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/Re-Jenkins-build-is-back-to-normal-flex-tlf-265-tp44026p44033.html
Sent from the Apache Flex Development mailing list archive at Nabb
If you can give me some pointers, I’d be happy to take a look.
Harbs
On Dec 31, 2014, at 3:47 AM, OmPrakash Muppirala wrote:
> I have spent more time than I wanted to on the failing Mustella tests. I
> have managed to fix quite a few, but there are a still a bunch of cases
> that are failing.
Erik,
Is it alright if I cherry pick this commit to the RC. Corrects a RTE for
the spark datagrid / it's skin?
-Mark
-Original Message-
From: mkess...@apache.org [mailto:mkess...@apache.org]
Sent: Monday, December 29, 2014 9:12 PM
To: comm...@flex.apache.org
Subject: git commit: [
Yes, if I replace it with "get" it compiles alright. `get' isn't a
reserved word nor a keyword. Not according to ECMA anyway. There is
AS3 code in the wild which uses this as a property name, so this must
be a problem with the lexer. In general, it does seem like a good idea
to make `get' a keyword
Could this be improved to have a better interface?.. Grepping through
the code I get 1388 hits for org.apache.flex.compiler.problems in Java
files alone. No one would think of this as being an easy way to find
an offending warning... But I don't think most people would even go as
far as looking int
19 matches
Mail list logo
