Re: [FALCON] Should Falcon compile older SDKs?

[Alex Harui]

On 9/17/13 9:21 PM, "Justin Mclean"  wrote:

>Hi,
>
>> Seems like the options are (at least):
>> 1) The release notes say that Falcon only works with 4.11 and greater so
>> 'too bad' if you try against an older SDK
>> 2) Hard-code Spark as the default theme
>> 3) Have Falcon report an warning if no theme is found in any config
>>file.
>> 4) Have Falcon inject a theme into air-config.xml if it is missing
>> 5) Have a Falcon installer inject a theme into air-config.xml.
>> 
>> #1 is the least work, but my second choice would be #3.
>
>1 is going to disappoint a lot of people (IMO), they will want to use the
>falcon compiler as a drop in replacement and wont understand why it's
>married to a version of the SDK and
As Erik pointed out, it could get really tricky to make it support old
SDKs.  The codegen for MXML changed in between some versions of Adobe Flex.

>2 is going to stop it working out of the box with any existing AIR
>project, it's a small change sure but better to not have to make everyone
>make that change for all projects if possible.
>
>Why not go with spark as a default (if required) if it not configured via
>a command line option or in the config file?
Because then you have hard-coded a dependency on the current Flex
framework.  It may not be what you want for FlexJS, for example.

There is a #6 which is to use flex-config.xml as a base.  More work, and
we'd have to see if there are any negatives, but might be what we have to
do.

>
>I assume there are going to be people who want to compile pure AS with
>Falcon how with that effect them?
We could not report the warning unless you are compiling a Flex project.

>
>> But Falcon reports a warning.  Why isn't that sufficient or even better?
>A warning is good. Why do you need to change the SDK's ResourceManager?
Because ResourceManagerImpl throws an error if it doesn't find all bundles
in all locales.  It should be more forgiving, IMO.  It seems like an
unnecessary requirement and you'll probably catch missing resources during
development.

>
>> At least with Falcon you'll find out that you don't have a bundle for a
>>locale.  MXMLC just copies a default.
>It fails to compile if the locale is missing..
I'm not seeing that if you have a folder but not all properties files. Are
you seeing differently?

-Alex

Re: [FALCON] Should Falcon compile older SDKs?

[Justin Mclean]

Hi,

> Seems like the options are (at least):
> 1) The release notes say that Falcon only works with 4.11 and greater so
> 'too bad' if you try against an older SDK
> 2) Hard-code Spark as the default theme
> 3) Have Falcon report an warning if no theme is found in any config file.
> 4) Have Falcon inject a theme into air-config.xml if it is missing
> 5) Have a Falcon installer inject a theme into air-config.xml.
> 
> #1 is the least work, but my second choice would be #3.

1 is going to disappoint a lot of people (IMO), they will want to use the 
falcon compiler as a drop in replacement and wont understand why it's married 
to a version of the SDK and
2 is going to stop it working out of the box with any existing AIR project, 
it's a small change sure but better to not have to make everyone make that 
change for all projects if possible.

Why not go with spark as a default (if required) if it not configured via a 
command line option or in the config file?

I assume there are going to be people who want to compile pure AS with Falcon 
how with that effect them?

>> A better solution would be to have an "en" locale, and then specify
>> changes in "en_US", "en_GB", "en_AU" etc as required. If there no "en_GB"
>> then it falls back to "en".
> Does the SDK do this today?

No but it wouldn't be hard to do and something I thought about for a while. 
Several other platforms handle things this way eg Android.

It would also make maintaing the en (and fr and pt) groups of resources much 
much easier.

> But Falcon reports a warning.  Why isn't that sufficient or even better?
A warning is good. Why do you need to change the SDK's ResourceManager?

> At least with Falcon you'll find out that you don't have a bundle for a 
> locale.  MXMLC just copies a default.  
It fails to compile if the locale is missing..

>  Neither compiler checks the contents of the bundle to find out if a 
> particular resource exists in the bundle so
> other misspelling can result in blanks.
Bundles can be modified at runtime so probably be hard to do that.

Thanks,
Justin

Re: [FALCON] Should Falcon compile older SDKs?

[Alex Harui]

On 9/17/13 5:12 PM, "Justin Mclean"  wrote:

>Hi,
>
>> If Erik doesn't want to upgrade to 4.11, he can add a  tag to
>>his SDK's
>> air-config.xml.  Are we ok with that?
>-1 to that, sorry but it's just going to confuse people.
Seems like the options are (at least):
1) The release notes say that Falcon only works with 4.11 and greater so
'too bad' if you try against an older SDK
2) Hard-code Spark as the default theme
3) Have Falcon report an warning if no theme is found in any config file.
4) Have Falcon inject a theme into air-config.xml if it is missing
5) Have a Falcon installer inject a theme into air-config.xml.

#1 is the least work, but my second choice would be #3.

>
>> My internal customer's app specifies a long list of locales, including
>> en_GB.  But they don't have custom resource bundles for en_GB because
>> MXMLC will swap in the en_US bundle when it can't find a bundle for
>>en_GB.
>A better solution would be to have an "en" locale, and then specify
>changes in "en_US", "en_GB", "en_AU" etc as required. If there no "en_GB"
>then it falls back to "en".
Does the SDK do this today?
>
>> I'm going to change the ResourceManager to ignore missing bundles
>>because the lookup mechanism
>> doesn't need it.
>-1 to that. It does need it, if there no fallback locale in the chain
>then error strings, UI elements, etc etc can be blank.
But Falcon reports a warning.  Why isn't that sufficient or even better?
At least with Falcon you'll find out that you don't have a bundle for a
locale.  MXMLC just copies a default.  You could have misspelled a bundle
name and not know it until runtime.   Neither compiler checks the contents
of the bundle to find out if a particular resource exists in the bundle so
other misspelling can result in blanks.  Plus it seems like it provides
more flexibility because you can load some resources later instead of at
startup time.

I suppose we could add more logic to throw if there is no bundle in any of
the locales if others think the compiler warning won't be sufficient.

Thoughts?
-Alex

Re: [FALCON] Should Falcon compile older SDKs?

[Alex Harui]

On 9/17/13 6:50 PM, "Justin Mclean"  wrote:

>Hi,
>
>Also depending on how AIR is added to the Flex SDK, it may use the air
>config file from the AIR SDK which will be missing the now required theme
>line.
I looked in my AIR 3.4 SDK and didn't see an air-config, so I thought the
only copy was ours.  Is it later SDKs that have it?  Or something else?

-Alex

Re: Dynamic validation in AS

[Justin Mclean]

Hi,

> validator.source = "{field}"; <<< Error: source attribute "{field}" can
> not be of Type String [from mx.validators::Validator/set]

validator.source = field;?

Justin

Re: Dynamic validation in AS

[Paul Hastings]

On 9/18/2013 9:22 AM, Oleg Konovalov wrote:

validator.source = "{field}"; <<< Error: source attribute "{field}" can


shouldn't that just be

validator.source=field;

Re: Dynamic validation in AS

[Oleg Konovalov]

OK, I tried the following:

private function validateRequiredField(field:TextInput):void {
var validator:StringValidator = new StringValidator();
validator.source = "{field}"; <<< Error: source attribute "{field}" can
not be of Type String [from mx.validators::Validator/set]
validator.property = "text";
validator.requiredFieldError = "This field is required";
validators.push(validator);
}

Any idea why I am getting that error above?
I am passing Spark's TextInput control there, not a String.
Calling it in "for" loop going through Dictionary of TextInput object,
where Key is column name.

How can I fix it?

TIA,
Oleg.


On Tue, Sep 17, 2013 at 8:58 AM, Franck Wolff wrote:

> Don't know if it could help, but you can check this:
>
> http://www.graniteds.org/public/docs/3.0.0/docs/reference/flex/en-US/html/graniteds.validation.html
>
> F.
>
>
> 2013/9/17 Oleg Konovalov 
>
> > On Sep 16, 2013 7:36 PM, "Oleg Konovalov"  wrote:
> >
> > > Hi,
> > >
> > > I need to validate dynamic form data in Flex 4.5 ADG, meaning that I
> > don't
> > > know column names,
> > > order, but if the attribute is Required, than I have to make sure user
> > > filled it in.
> > > From all examples I have seen, validations is done in MXML, but in my
> > case
> > > since data is dynamic, it should be done in AS.
> > >
> > > Any samples?
> > >
> > > Data comes dynamically to ADG,
> > > but user can Add or Edit row in dynamically built Form.
> > >
> > > Please advise.
> > >
> > > TIA,
> > > Oleg
> > >
> >
>



-- 
Thank you,
Oleg.

Re: [FALCON] Should Falcon compile older SDKs?

[Justin Mclean]

Hi,

Also depending on how AIR is added to the Flex SDK, it may use the air config 
file from the AIR SDK which will be missing the now required theme line.

Justin

Re: [FALCON] Should Falcon compile older SDKs?

[Justin Mclean]

Hi,

> If Erik doesn't want to upgrade to 4.11, he can add a  tag to his SDK's
> air-config.xml.  Are we ok with that?
-1 to that, sorry but it's just going to confuse people.

> My internal customer's app specifies a long list of locales, including
> en_GB.  But they don't have custom resource bundles for en_GB because
> MXMLC will swap in the en_US bundle when it can't find a bundle for en_GB.
A better solution would be to have an "en" locale, and then specify changes in 
"en_US", "en_GB", "en_AU" etc as required. If there no "en_GB" then it falls 
back to "en".

> I'm going to change the ResourceManager to ignore missing bundles because the 
> lookup mechanism
> doesn't need it. 
-1 to that. It does need it, if there no fallback locale in the chain then 
error strings, UI elements, etc etc can be blank.

Thanks,
Justin

Re: Building SDK from sources and locales support

[Justin Mclean]

Hi,

> Thank you very much, running the other.locales ant target right now.. maybe
> we could drop a note about this in the README?
Done.

Justin

Re: Building SDK from sources and locales support

[Justin Mclean]

Hi,

> I noticed that, in the compiled and "IDEnized" SDK, the
> {sdkhome}/frameworks/locale/... folders don't contain the *_rb.swc files,
> with the exception of the en_US locale. Is this the intended behavior?
By default the SDK will compile for en_US. You can change this by passing 
-Dlocale= when compiling or editing this in the build.proberties file.

> In README, I read "The Apache Flex SDK defaults to using the en_US locale
> and SDK error messages are by default displayed in American English".
> Shouldn't the SDK, by default, include all the supported locales, or am I
> misunderstanding the README?
It does included all supported locales, you just need to compile them. This 
will compile all locals amd it takes about 1/2 hour or so.
ant other_locales 

Hope that helps,
Justin

Re: [FALCON] Should Falcon compile older SDKs?

[OmPrakash Muppirala]

On Sep 17, 2013 12:22 PM, "Erik de Bruin"  wrote:
>
> >>> Erik compiles his AIR app against 4.10 with MXMLC.  Works fine.  Then
> >>>uses
> >>> Falcon and gets a bunch of errors about styles only supported in Spark
> >>> theme.  The root cause is that the air-config.xml in every shipping
> >>> version of Flex doesn't have a  tag and MXMLC is hard-coded to
> >>> assume Spark.   Darrell and I would prefer not to hard-code stuff like
> >>> that in Falcon and will change the air-config.xml in 4.11 so if you
use
> >>> the Falcon/4.11 combination the app compiles cleanly.  If Erik doesn't
> >>> want to upgrade to 4.11, he can add a  tag to his SDK's
> >>> air-config.xml.  Are we ok with that?
> >>
> >>I'm not sure what you're saying. If I don't want to upgrade, I'll be
> >>using 'old compiler/4.10', correct? In which case, all will be fine,
> >>as the app compiles fine with those. Or do you mean upgrade to 4.11
> >>but not to Falcon ('old compiler/4.11')? In which case, how does the
> >>'old compiler' handle having a default theme added to the AIR config?
> >>I'd guess that it won't mind, correct?
> > I'm assuming you have some desire to use Falcon.  And right now, when
you
> > do use Falcon your app spits out those errors.  Are you ok with the
> > official answer being "upgrade from 4.10 to 4.11 and/or modify your
> > air-config.xml"?
>
> Certainly. If I want to use the new compiler, it's not unreasonable to
> expect of me that I use a new SDK as well.

I am not sure what exactly the benefits are when switching to the new
Falcon compiler.  Why exactly would I go through the hassle of modifying
all these?

I think Alex mentioned a while ago that we cannot expect compile times to
improve a lot with Falcon.  Am I mistaken?

If it is tied to a new SDK at least, it makes sense.

Thanks,
Om

>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl

Re: Scale-9 Design Tools for FXG files in Apache Flex

[Sebastian Mohr]

OK … here is the way how I solved it. Based on this tutorial [1], I have put 
the scaling attributes into the 2 FXG files 1) menuMiddle_upSkin.fxg 
and 2) menuMiddle_selectedSkin.fxg. Thereafter, I have linked the FXG
files with the ToggleButton skin 3) MenuMiddleToggleButtonSkin.mxml. 
Unfortunately, I still don't know how to get the scaling information out of 
Illustrator CS5.5 or Flash Catalyst CS5.5, which not that handy when creating 
lots of these skins types. If you a recommendation, please, let me know. Hope 
this helps, and, thanks for help!

[1] http://flexdevtips.blogspot.de/2011/10/fxg-scale-grid.html


- 
Sebastian (PPMC)
Interaction Designer

Looking for a Login Example with Apache Flex? Please check out this code: 
http://code.google.com/p/masuland/wiki/LoginExample


1) menuMiddle_upSkin.fxg


http://ns.adobe.com/fxg/2008"; version="2.0"
scaleGridLeft="22" scaleGridRight="48" scaleGridTop="1" 
scaleGridBottom="46"
>











2) menuMiddle_selectedSkin.fxg

http://ns.adobe.com/fxg/2008"; version="2.0"
scaleGridLeft="22" scaleGridRight="48" scaleGridTop="1" 
scaleGridBottom="46"
>











3) MenuMiddleToggleButtonSkin.mxml


http://ns.adobe.com/mxml/2009";
xmlns:menu="assets.menu.*"
height="47"
>


[HostComponent("spark.components.ToggleButton")]



























On Sep 16, 2013, at 7:51 PM, OmPrakash Muppirala  wrote:

> Here is a very good set of instructions on how to build and use FXG skins
> [1].  Apparently you can edit FXG using the design view of Flash Builder
> (not sure which version you tried)
> 
> From the article, here are the restrictions when using scalegrids in FXG.
> Do you have any of these in your skins?
> 
> =
> Scale grid
> 
> Scale grids have some limitations that must be considered when designing
> graphics using FXG.
> 
> Scale grid values must be inside the boundaries of the graphic and must not
> overlap (that is, left boundary < scaleGridLeft < scaleGridRight < right
> boundary).
> 
> Scale grids will not work if the graphic contains any Group elements.
> 
> Scale grids will not work if elements have alpha applied. Instead, apply
> alpha to the stroke and fill elements.
> =
> 
> 
> [1] http://www.adobe.com/devnet/flex/articles/mobile-skinning-part1.html
> 
> 
> On Mon, Sep 16, 2013 at 10:43 AM, OmPrakash Muppirala
> wrote:
> 
>> On Mon, Sep 16, 2013 at 10:27 AM, Alex Harui  wrote:
>> 
>>> I don't know much about the rules for scaleGrid and skins.  I haven't
>>> spent any time in that area.
>>> 
>>> But again, Path and Text are still vectors.  You shouldn't need scaleGrid
>>> to scale them.
>>> 
>>> -Alex
>>> 
>> 
>> Even though they are vectors, they are built for a particular form
>> factor.  When using it the user might want to use it in a different form
>> factor but still expect it to scale correctly. We do that a lot in the Flex
>> Mobile skins, ex. [1]
>> 
>> Thanks,
>> Om
>> 
>> [1]
>> https://fisheye6.atlassian.com/browse/~br=develop/flex-sdk/frameworks/projects/mobiletheme/src/spark/skins/mobile160/assets/Button_down.fxg?hb=true
>> 
>> 
>> 
>>> 
>>> On 9/16/13 10:17 AM, "Sebastian Mohr"  wrote:
>>> 
 Thanks for your reply ... I wanted to use these attributes for a bunch of
 vector  skins like ...
 
 >>> scaleGridBottom="47" />
 
 Inside are a number of  and  that I have created
 with Flash Catalyst CS5.5.
 
 for the moment I get this error:
 Error: ScaleGrid properties can not be set on this Group since at least
 one
 child element is a DisplayObject.
 
 Wouldn't this be possible? Thanks.
 
 --
 Sebastian (PPMC)
 Interaction Designer
 
 Looking for a Login Example with Apache Flex? Please check out this code:
 http://code.google.com/p/masuland/wiki/LoginExample
 
 
 
 On Mon, Sep 16, 2013 at 6:45 PM, Alex Harui  wrote:
 
> Why do you want to scale vector graphics via scale9?
> 
> On 9/16/13 5:09 AM, "Sebastian Mohr"  wrote:
> 
>> Just wanted to know if you have a recommendation what would be the
>> quickest
>> way to add scale-9 information to FXG files. For PNG files I usually
> use
>> Flex Builder 3 which has a "Edit Scale Grid" Button in the CSS file
>> "Design
>> View" [1], but, for FXG files th

Re: [FALCON] Should Falcon compile older SDKs?

[Alex Harui]

On 9/17/13 12:38 PM, "OmPrakash Muppirala"  wrote:


>I am not sure what exactly the benefits are when switching to the new
>Falcon compiler.  Why exactly would I go through the hassle of modifying
>all these?
>
>I think Alex mentioned a while ago that we cannot expect compile times to
>improve a lot with Falcon.  Am I mistaken?
Hard to say what the net gain will be.  If we can get Falcon to compile
the SDK, that would be a good way to measure the difference.

-Alex

RE: [FALCON] Should Falcon compile older SDKs?

[Frédéric THOMAS]

> I'm assuming you have some desire to use Falcon.  And right now, when you
do use Falcon your app spits out those errors.  Are you ok with the official
answer being "upgrade from 4.10 to 4.11 and/or modify your air-config.xml"?

Until it is well documented or we offer a patch, it seems acceptable to me
to agree with.

-Fred

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] 
Envoyé : mardi 17 septembre 2013 21:10
À : dev@flex.apache.org
Objet : Re: [FALCON] Should Falcon compile older SDKs?



On 9/17/13 11:36 AM, "Erik de Bruin"  wrote:

>> Erik compiles his AIR app against 4.10 with MXMLC.  Works fine.  Then 
>>uses  Falcon and gets a bunch of errors about styles only supported in 
>>Spark  theme.  The root cause is that the air-config.xml in every 
>>shipping  version of Flex doesn't have a  tag and MXMLC is 
>>hard-coded to
>> assume Spark.   Darrell and I would prefer not to hard-code stuff like
>> that in Falcon and will change the air-config.xml in 4.11 so if you 
>>use  the Falcon/4.11 combination the app compiles cleanly.  If Erik 
>>doesn't  want to upgrade to 4.11, he can add a  tag to his 
>>SDK's  air-config.xml.  Are we ok with that?
>
>I'm not sure what you're saying. If I don't want to upgrade, I'll be 
>using 'old compiler/4.10', correct? In which case, all will be fine, as 
>the app compiles fine with those. Or do you mean upgrade to 4.11 but 
>not to Falcon ('old compiler/4.11')? In which case, how does the 'old 
>compiler' handle having a default theme added to the AIR config?
>I'd guess that it won't mind, correct?
I'm assuming you have some desire to use Falcon.  And right now, when you do
use Falcon your app spits out those errors.  Are you ok with the official
answer being "upgrade from 4.10 to 4.11 and/or modify your air-config.xml"?

Re: [FALCON] Should Falcon compile older SDKs?

[Erik de Bruin]

Yeah, there is an option for version hell there... On the other hand,
if the libs were updated to work with Falcon, they would still work
with the old compiler, if I'm not mistaken?

EdB



On Tue, Sep 17, 2013 at 7:00 PM, OmPrakash Muppirala
 wrote:
> On Tue, Sep 17, 2013 at 9:30 AM, Erik de Bruin  wrote:
>
>> I say don't worry too much about backwards compatibility, that is
>> always a sure road to over complicating a piece of software. What I do
>> think should happen is to make the compiler 'selectable'... So you
>> compile with either the old one (default for some time), or the new
>> one. That way people can evolve new projects to use the new compiler,
>> but be able to make simple fixes to legacy projects using the old one.
>>
>> EdB
>>
>>
> How would this approach affect third party libraries?
>
> Thanks,
> Om
>
>
>
>>
>>
>>
>>
>> On Tue, Sep 17, 2013 at 5:04 PM, Alex Harui  wrote:
>> > Falcon is catching subtle coding issues that MXMLC didn't catch like
>> duplicate variable declarations, ambigous definitions and more.  Therefore,
>> there is a good chance that when you compile an existing app with Falcon
>> you might have to fix some of your code.  So far, I haven't seen anyone
>> want to make Falcon less 'strict'.
>> >
>> > But I just ran into an issue with resource bundles where the current
>> Falcon code reports a compile error if it can't find a bundle for a locale.
>>  MXMLC seems to do some magic and makes the en_US bundle also act as the
>> bundle for the locale that is missing a bundle.  It has to do that because
>> the SDKs currently throw an error if a locale is missing a bundle.
>> >
>> > But is that what we want?  I would think you should get a warning if a
>> bundle is missing and the SDK should change its code so that if a bundle is
>> missing it just falls through to the next bundle in the locale chain, if
>> any.  But such a change would mean that, if you compile an existing project
>> against an older SDK, even Apache Flex 4.10.0, your app may throw an error
>> if you are missing a bundle.
>> >
>> > Thoughts?
>> > -Alex
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FALCON] Should Falcon compile older SDKs?

[Erik de Bruin]

>>> Erik compiles his AIR app against 4.10 with MXMLC.  Works fine.  Then
>>>uses
>>> Falcon and gets a bunch of errors about styles only supported in Spark
>>> theme.  The root cause is that the air-config.xml in every shipping
>>> version of Flex doesn't have a  tag and MXMLC is hard-coded to
>>> assume Spark.   Darrell and I would prefer not to hard-code stuff like
>>> that in Falcon and will change the air-config.xml in 4.11 so if you use
>>> the Falcon/4.11 combination the app compiles cleanly.  If Erik doesn't
>>> want to upgrade to 4.11, he can add a  tag to his SDK's
>>> air-config.xml.  Are we ok with that?
>>
>>I'm not sure what you're saying. If I don't want to upgrade, I'll be
>>using 'old compiler/4.10', correct? In which case, all will be fine,
>>as the app compiles fine with those. Or do you mean upgrade to 4.11
>>but not to Falcon ('old compiler/4.11')? In which case, how does the
>>'old compiler' handle having a default theme added to the AIR config?
>>I'd guess that it won't mind, correct?
> I'm assuming you have some desire to use Falcon.  And right now, when you
> do use Falcon your app spits out those errors.  Are you ok with the
> official answer being "upgrade from 4.10 to 4.11 and/or modify your
> air-config.xml"?

Certainly. If I want to use the new compiler, it's not unreasonable to
expect of me that I use a new SDK as well.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FALCON] Should Falcon compile older SDKs?

[Alex Harui]

On 9/17/13 11:36 AM, "Erik de Bruin"  wrote:

>> Erik compiles his AIR app against 4.10 with MXMLC.  Works fine.  Then
>>uses
>> Falcon and gets a bunch of errors about styles only supported in Spark
>> theme.  The root cause is that the air-config.xml in every shipping
>> version of Flex doesn't have a  tag and MXMLC is hard-coded to
>> assume Spark.   Darrell and I would prefer not to hard-code stuff like
>> that in Falcon and will change the air-config.xml in 4.11 so if you use
>> the Falcon/4.11 combination the app compiles cleanly.  If Erik doesn't
>> want to upgrade to 4.11, he can add a  tag to his SDK's
>> air-config.xml.  Are we ok with that?
>
>I'm not sure what you're saying. If I don't want to upgrade, I'll be
>using 'old compiler/4.10', correct? In which case, all will be fine,
>as the app compiles fine with those. Or do you mean upgrade to 4.11
>but not to Falcon ('old compiler/4.11')? In which case, how does the
>'old compiler' handle having a default theme added to the AIR config?
>I'd guess that it won't mind, correct?
I'm assuming you have some desire to use Falcon.  And right now, when you
do use Falcon your app spits out those errors.  Are you ok with the
official answer being "upgrade from 4.10 to 4.11 and/or modify your
air-config.xml"?

Re: [FALCON] Should Falcon compile older SDKs?

[Erik de Bruin]

> Erik compiles his AIR app against 4.10 with MXMLC.  Works fine.  Then uses
> Falcon and gets a bunch of errors about styles only supported in Spark
> theme.  The root cause is that the air-config.xml in every shipping
> version of Flex doesn't have a  tag and MXMLC is hard-coded to
> assume Spark.   Darrell and I would prefer not to hard-code stuff like
> that in Falcon and will change the air-config.xml in 4.11 so if you use
> the Falcon/4.11 combination the app compiles cleanly.  If Erik doesn't
> want to upgrade to 4.11, he can add a  tag to his SDK's
> air-config.xml.  Are we ok with that?

I'm not sure what you're saying. If I don't want to upgrade, I'll be
using 'old compiler/4.10', correct? In which case, all will be fine,
as the app compiles fine with those. Or do you mean upgrade to 4.11
but not to Falcon ('old compiler/4.11')? In which case, how does the
'old compiler' handle having a default theme added to the AIR config?
I'd guess that it won't mind, correct?

> My internal customer's app specifies a long list of locales, including
> en_GB.  But they don't have custom resource bundles for en_GB because
> MXMLC will swap in the en_US bundle when it can't find a bundle for en_GB.
>  When compiling with Falcon there will be a warning that a locale is
> missing a bundle.  Then, if you run against 4.10 or earlier, your app
> won't run because those versions of the SDK require that all locales have
> all of the same bundles, but if you run against 4.11, I'm going to change
> the ResourceManager to ignore missing bundles because the lookup mechanism
> doesn't need it.  It is ok with a locale missing a bundle and will search
> for the next locale that has one.

So, you're saying this will only be a problem if you use 'Falcon/4.10'
(new compiler, old SDK). I'd say that isn't a problem, Falcon is new
and should only be 'supported' on new SDKs. Looking forward, not back.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

RE: Building SDK from sources and locales support

[Frédéric THOMAS]

>From what I remember, not compiling the compiler locales created some issues 
>at me as my OS is French, it looked at the localized.jars but didn't find 
>them, so, what you can do, given you found the name of the variable is to add 
>it to your build.properties -> localized.jars=true

-Fred

-Message d'origine-
De : Cosma Colanicchia [mailto:cosma...@gmail.com] 
Envoyé : mardi 17 septembre 2013 18:27
À : dev@flex.apache.org
Objet : Re: Building SDK from sources and locales support

I'm looking at the binary-release target, trying to identify the required 
targets to run in order to IDEnize and mavenize an SDK from sources.

 - setup-binary-release (yes and no: we don't want to clean /in, but we want to 
set the localized.jars property to true)
 - main (yes)
 - frameworks-rsls (maybe?)
 - sample-themes (maybe?)
 - checkintests (no)
 - doc (no)
 - other.locales (yes, otherwise mavenized SDK will fail to resolve 
dependencies for some -rb.swc artifacts)
 - binary-package (no)
 - additional-packages (maybe, isn't the ant tasks jar bundled with the 
IDEnized sdk?)

So

Unfortunately, there's no way to set the localized.jars property without also 
clearing the /in folder, I'd need to add one or two targets to the build.xml in 
my sandbox, or externally force the value of the localized.jars from the ant 
command line.

Anyway, I'd be perfectly happy with english compiler messages - is this the 
effect of not setting the localized.jars to true?




2013/9/17 Frédéric THOMAS 

> Maybe yes, know as well there are many other targets, run ant -p to 
> get them all displayed and be sure to run the IDE script you need from 
> the sdk/ide folder, I guess as well you will need to create the 
> compiler locales as well if you're not US but I can't remember the ant 
> build variable to set, maybe someone else remember otherwise look into 
> the release target of the build.xml.
>
> -Fred
>
> -Message d'origine-
> De : Cosma Colanicchia [mailto:cosma...@gmail.com] Envoyé : mardi 17 
> septembre 2013 17:52 À : dev@flex.apache.org Objet : Re: Building SDK 
> from sources and locales support
>
> Thank you very much, running the other.locales ant target right now..
> maybe we could drop a note about this in the README?
>
>
> 2013/9/17 Frédéric THOMAS 
>
> > The locales are in and are well managed by the Maven converter / 
> > deployer, use the SDK provided by the Installer or be sure you ran 
> > ant -other.locale after a standard ant build from the sources to 
> > generate
> the locales.
> >
> > -Fred
> >
> > -Message d'origine-
> > De : Cosma Colanicchia [mailto:cosma...@gmail.com] Envoyé : mardi 17 
> > septembre 2013 17:31 À : dev@flex.apache.org Objet : Building SDK 
> > from sources and locales support
> >
> > Hi, I'm trying to build the latest SDK sources - I need to use it in 
> > Flash Builder and as mavenized artifacts.
> >
> > I noticed that, in the compiled and "IDEnized" SDK, the 
> > {sdkhome}/frameworks/locale/... folders don't contain the *_rb.swc 
> > files, with the exception of the en_US locale. Is this the intended 
> > behavior? I see that the Adobe 4.6 SDK containes these compiled 
> > resource bundles for all supported locales.
> >
> > In README, I read "The Apache Flex SDK defaults to using the en_US 
> > locale and SDK error messages are by default displayed in American
> English".
> > Shouldn't the SDK, by default, include all the supported locales, or 
> > am I misunderstanding the README?
> >
> > As a side note, I noticed this as a suspect while searching for the 
> > cause of a "Could not find artifact 
> > com.adobe.flash.framework:playerglobal:rb.swc:11.1" - seems that the 
> > pom generated by the mavenizer references it (the 
> > com.adobe.flex.framework.flex-framework pom), but the related 
> > artifact was not generated nor deployed by the mavenizer tool.
> >
> > Any help? TIA
> >
>

MultiBitmapSource

[Maurice Amsellem]

Hi Community,

MultiBitmapSource getSource(dpi) method is called 3 times in the SDK with 
exactly the same code:

 var app:Object = FlexGlobals.topLevelApplication;
var dpi:Number;
if ("runtimeDPI" in app)
dpi = app["runtimeDPI"];
else
dpi = DensityUtil.getRuntimeDPI();
var multiSource:Object = 
MultiDPIBitmapSource(source).getSource(dpi);


Wouldn't it be better to have this code embedded in the MultiBitmapSource 
getSource() method ?

The desiredDPI:Number arg could be made optional, so as not to break existing 
code, and use the above code when desiredDPI is NaN .

Another advantage of this is that it will allow to use MBS with other classes, 
such as BitmapAssets.

What do you think?

Regards,

Maurice

RE: [FALCON] Should Falcon compile older SDKs?

[Kessler CTR Mark J]

Clarifying... I support more strict.  Warnings on simple things or corrections 
if they are affected in our Flex SDK.  Giving the end developer a choice 
between the compilers is a fine option.

-Mark

-Original Message-
From: Kessler CTR Mark J [mailto:mark.kessler@usmc.mil] 
Sent: Tuesday, September 17, 2013 1:50 PM
To: dev@flex.apache.org
Subject: RE: [FALCON] Should Falcon compile older SDKs?

Well if it's overall improvement, wouldn't it be worth the time to correct the 
issues anyways?  

What is the volume we are talking about?



-Mark

RE: FlexUnit License

[Michael A. Labriola]

>"He may be also able to provide a more recent version of Mockolate."

This is good. FlexUnit may not be built against the latest right now as I 
believe there were some method signature changes, so it's possible upgrading to 
the latest will cause some minor library changes. I am also going to commit a 
change in the next week to allow FlexUnit to get stack traces in modern release 
players since this is now available in the player.

Mike

Re: [FALCON] Should Falcon compile older SDKs?

[Alex Harui]

I think we have consensus on stricter compilation.  But here are two
scenarios that aren't syntax-related.

Erik compiles his AIR app against 4.10 with MXMLC.  Works fine.  Then uses
Falcon and gets a bunch of errors about styles only supported in Spark
theme.  The root cause is that the air-config.xml in every shipping
version of Flex doesn't have a  tag and MXMLC is hard-coded to
assume Spark.   Darrell and I would prefer not to hard-code stuff like
that in Falcon and will change the air-config.xml in 4.11 so if you use
the Falcon/4.11 combination the app compiles cleanly.  If Erik doesn't
want to upgrade to 4.11, he can add a  tag to his SDK's
air-config.xml.  Are we ok with that?

My internal customer's app specifies a long list of locales, including
en_GB.  But they don't have custom resource bundles for en_GB because
MXMLC will swap in the en_US bundle when it can't find a bundle for en_GB.
 When compiling with Falcon there will be a warning that a locale is
missing a bundle.  Then, if you run against 4.10 or earlier, your app
won't run because those versions of the SDK require that all locales have
all of the same bundles, but if you run against 4.11, I'm going to change
the ResourceManager to ignore missing bundles because the lookup mechanism
doesn't need it.  It is ok with a locale missing a bundle and will search
for the next locale that has one.

Thoughts?
-Alex

On 9/17/13 10:57 AM, "Kessler CTR Mark J" 
wrote:

>Clarifying... I support more strict.  Warnings on simple things or
>corrections if they are affected in our Flex SDK.  Giving the end
>developer a choice between the compilers is a fine option.
>
>-Mark
>
>-Original Message-
>From: Kessler CTR Mark J [mailto:mark.kessler@usmc.mil]
>Sent: Tuesday, September 17, 2013 1:50 PM
>To: dev@flex.apache.org
>Subject: RE: [FALCON] Should Falcon compile older SDKs?
>
>Well if it's overall improvement, wouldn't it be worth the time to
>correct the issues anyways?
>
>What is the volume we are talking about?
>
>
>
>-Mark

RE: [FALCON] Should Falcon compile older SDKs?

[Kessler CTR Mark J]

Well if it's overall improvement, wouldn't it be worth the time to correct the 
issues anyways?  

What is the volume we are talking about?



-Mark

-Original Message-
From: Erik de Bruin [mailto:e...@ixsoftware.nl] 
Sent: Tuesday, September 17, 2013 1:41 PM
To: dev@flex.apache.org
Subject: Re: [FALCON] Should Falcon compile older SDKs?

Yeah, there is an option for version hell there... On the other hand,
if the libs were updated to work with Falcon, they would still work
with the old compiler, if I'm not mistaken?

EdB

Re: [FALCON] Should Falcon compile older SDKs?

[Erik de Bruin]

I say don't worry too much about backwards compatibility, that is
always a sure road to over complicating a piece of software. What I do
think should happen is to make the compiler 'selectable'... So you
compile with either the old one (default for some time), or the new
one. That way people can evolve new projects to use the new compiler,
but be able to make simple fixes to legacy projects using the old one.

EdB





On Tue, Sep 17, 2013 at 5:04 PM, Alex Harui  wrote:
> Falcon is catching subtle coding issues that MXMLC didn't catch like 
> duplicate variable declarations, ambigous definitions and more.  Therefore, 
> there is a good chance that when you compile an existing app with Falcon you 
> might have to fix some of your code.  So far, I haven't seen anyone want to 
> make Falcon less 'strict'.
>
> But I just ran into an issue with resource bundles where the current Falcon 
> code reports a compile error if it can't find a bundle for a locale.  MXMLC 
> seems to do some magic and makes the en_US bundle also act as the bundle for 
> the locale that is missing a bundle.  It has to do that because the SDKs 
> currently throw an error if a locale is missing a bundle.
>
> But is that what we want?  I would think you should get a warning if a bundle 
> is missing and the SDK should change its code so that if a bundle is missing 
> it just falls through to the next bundle in the locale chain, if any.  But 
> such a change would mean that, if you compile an existing project against an 
> older SDK, even Apache Flex 4.10.0, your app may throw an error if you are 
> missing a bundle.
>
> Thoughts?
> -Alex



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

RE: Building SDK from sources and locales support

[Frédéric THOMAS]

The locales are in and are well managed by the Maven converter / deployer, use 
the SDK provided by the Installer or be sure you ran ant -other.locale after a 
standard ant build from the sources to generate the locales.

-Fred

-Message d'origine-
De : Cosma Colanicchia [mailto:cosma...@gmail.com] 
Envoyé : mardi 17 septembre 2013 17:31
À : dev@flex.apache.org
Objet : Building SDK from sources and locales support

Hi, I'm trying to build the latest SDK sources - I need to use it in Flash 
Builder and as mavenized artifacts.

I noticed that, in the compiled and "IDEnized" SDK, the 
{sdkhome}/frameworks/locale/... folders don't contain the *_rb.swc files, with 
the exception of the en_US locale. Is this the intended behavior? I see that 
the Adobe 4.6 SDK containes these compiled resource bundles for all supported 
locales.

In README, I read "The Apache Flex SDK defaults to using the en_US locale and 
SDK error messages are by default displayed in American English".
Shouldn't the SDK, by default, include all the supported locales, or am I 
misunderstanding the README?

As a side note, I noticed this as a suspect while searching for the cause of a 
"Could not find artifact com.adobe.flash.framework:playerglobal:rb.swc:11.1" - 
seems that the pom generated by the mavenizer references it (the 
com.adobe.flex.framework.flex-framework pom), but the related artifact was not 
generated nor deployed by the mavenizer tool.

Any help? TIA

Re: [FALCON] Should Falcon compile older SDKs?

[OmPrakash Muppirala]

On Tue, Sep 17, 2013 at 9:30 AM, Erik de Bruin  wrote:

> I say don't worry too much about backwards compatibility, that is
> always a sure road to over complicating a piece of software. What I do
> think should happen is to make the compiler 'selectable'... So you
> compile with either the old one (default for some time), or the new
> one. That way people can evolve new projects to use the new compiler,
> but be able to make simple fixes to legacy projects using the old one.
>
> EdB
>
>
How would this approach affect third party libraries?

Thanks,
Om



>
>
>
>
> On Tue, Sep 17, 2013 at 5:04 PM, Alex Harui  wrote:
> > Falcon is catching subtle coding issues that MXMLC didn't catch like
> duplicate variable declarations, ambigous definitions and more.  Therefore,
> there is a good chance that when you compile an existing app with Falcon
> you might have to fix some of your code.  So far, I haven't seen anyone
> want to make Falcon less 'strict'.
> >
> > But I just ran into an issue with resource bundles where the current
> Falcon code reports a compile error if it can't find a bundle for a locale.
>  MXMLC seems to do some magic and makes the en_US bundle also act as the
> bundle for the locale that is missing a bundle.  It has to do that because
> the SDKs currently throw an error if a locale is missing a bundle.
> >
> > But is that what we want?  I would think you should get a warning if a
> bundle is missing and the SDK should change its code so that if a bundle is
> missing it just falls through to the next bundle in the locale chain, if
> any.  But such a change would mean that, if you compile an existing project
> against an older SDK, even Apache Flex 4.10.0, your app may throw an error
> if you are missing a bundle.
> >
> > Thoughts?
> > -Alex
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

RE: Building SDK from sources and locales support

[Frédéric THOMAS]

Well, I'm not sure to remember if I ran an ant -main or - 
binary-release(-noclean), so, see if it works for you.

-Message d'origine-
De : Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Envoyé : mardi 17 septembre 2013 18:40
À : dev@flex.apache.org
Objet : RE: Building SDK from sources and locales support

>From what I remember, not compiling the compiler locales created some issues 
>at me as my OS is French, it looked at the localized.jars but didn't find 
>them, so, what you can do, given you found the name of the variable is to add 
>it to your build.properties -> localized.jars=true

-Fred

-Message d'origine-
De : Cosma Colanicchia [mailto:cosma...@gmail.com] Envoyé : mardi 17 septembre 
2013 18:27 À : dev@flex.apache.org Objet : Re: Building SDK from sources and 
locales support

I'm looking at the binary-release target, trying to identify the required 
targets to run in order to IDEnize and mavenize an SDK from sources.

 - setup-binary-release (yes and no: we don't want to clean /in, but we want to 
set the localized.jars property to true)
 - main (yes)
 - frameworks-rsls (maybe?)
 - sample-themes (maybe?)
 - checkintests (no)
 - doc (no)
 - other.locales (yes, otherwise mavenized SDK will fail to resolve 
dependencies for some -rb.swc artifacts)
 - binary-package (no)
 - additional-packages (maybe, isn't the ant tasks jar bundled with the 
IDEnized sdk?)

So

Unfortunately, there's no way to set the localized.jars property without also 
clearing the /in folder, I'd need to add one or two targets to the build.xml in 
my sandbox, or externally force the value of the localized.jars from the ant 
command line.

Anyway, I'd be perfectly happy with english compiler messages - is this the 
effect of not setting the localized.jars to true?




2013/9/17 Frédéric THOMAS 

> Maybe yes, know as well there are many other targets, run ant -p to 
> get them all displayed and be sure to run the IDE script you need from 
> the sdk/ide folder, I guess as well you will need to create the 
> compiler locales as well if you're not US but I can't remember the ant 
> build variable to set, maybe someone else remember otherwise look into 
> the release target of the build.xml.
>
> -Fred
>
> -Message d'origine-
> De : Cosma Colanicchia [mailto:cosma...@gmail.com] Envoyé : mardi 17 
> septembre 2013 17:52 À : dev@flex.apache.org Objet : Re: Building SDK 
> from sources and locales support
>
> Thank you very much, running the other.locales ant target right now..
> maybe we could drop a note about this in the README?
>
>
> 2013/9/17 Frédéric THOMAS 
>
> > The locales are in and are well managed by the Maven converter / 
> > deployer, use the SDK provided by the Installer or be sure you ran 
> > ant -other.locale after a standard ant build from the sources to 
> > generate
> the locales.
> >
> > -Fred
> >
> > -Message d'origine-
> > De : Cosma Colanicchia [mailto:cosma...@gmail.com] Envoyé : mardi 17 
> > septembre 2013 17:31 À : dev@flex.apache.org Objet : Building SDK 
> > from sources and locales support
> >
> > Hi, I'm trying to build the latest SDK sources - I need to use it in 
> > Flash Builder and as mavenized artifacts.
> >
> > I noticed that, in the compiled and "IDEnized" SDK, the 
> > {sdkhome}/frameworks/locale/... folders don't contain the *_rb.swc 
> > files, with the exception of the en_US locale. Is this the intended 
> > behavior? I see that the Adobe 4.6 SDK containes these compiled 
> > resource bundles for all supported locales.
> >
> > In README, I read "The Apache Flex SDK defaults to using the en_US 
> > locale and SDK error messages are by default displayed in American
> English".
> > Shouldn't the SDK, by default, include all the supported locales, or 
> > am I misunderstanding the README?
> >
> > As a side note, I noticed this as a suspect while searching for the 
> > cause of a "Could not find artifact 
> > com.adobe.flash.framework:playerglobal:rb.swc:11.1" - seems that the 
> > pom generated by the mavenizer references it (the 
> > com.adobe.flex.framework.flex-framework pom), but the related 
> > artifact was not generated nor deployed by the mavenizer tool.
> >
> > Any help? TIA
> >
>

Re: Building SDK from sources and locales support

[Cosma Colanicchia]

I'm looking at the binary-release target, trying to identify the required
targets to run in order to IDEnize and mavenize an SDK from sources.

 - setup-binary-release (yes and no: we don't want to clean /in, but we
want to set the localized.jars property to true)
 - main (yes)
 - frameworks-rsls (maybe?)
 - sample-themes (maybe?)
 - checkintests (no)
 - doc (no)
 - other.locales (yes, otherwise mavenized SDK will fail to resolve
dependencies for some -rb.swc artifacts)
 - binary-package (no)
 - additional-packages (maybe, isn't the ant tasks jar bundled with the
IDEnized sdk?)

So

Unfortunately, there's no way to set the localized.jars property without
also clearing the /in folder, I'd need to add one or two targets to the
build.xml in my sandbox, or externally force the value of the
localized.jars from the ant command line.

Anyway, I'd be perfectly happy with english compiler messages - is this the
effect of not setting the localized.jars to true?




2013/9/17 Frédéric THOMAS 

> Maybe yes, know as well there are many other targets, run ant -p to get
> them all displayed and be sure to run the IDE script you need from the
> sdk/ide folder, I guess as well you will need to create the compiler
> locales as well if you're not US but I can't remember the ant build
> variable to set, maybe someone else remember otherwise look into the
> release target of the build.xml.
>
> -Fred
>
> -Message d'origine-
> De : Cosma Colanicchia [mailto:cosma...@gmail.com]
> Envoyé : mardi 17 septembre 2013 17:52
> À : dev@flex.apache.org
> Objet : Re: Building SDK from sources and locales support
>
> Thank you very much, running the other.locales ant target right now..
> maybe we could drop a note about this in the README?
>
>
> 2013/9/17 Frédéric THOMAS 
>
> > The locales are in and are well managed by the Maven converter /
> > deployer, use the SDK provided by the Installer or be sure you ran ant
> > -other.locale after a standard ant build from the sources to generate
> the locales.
> >
> > -Fred
> >
> > -Message d'origine-
> > De : Cosma Colanicchia [mailto:cosma...@gmail.com] Envoyé : mardi 17
> > septembre 2013 17:31 À : dev@flex.apache.org Objet : Building SDK from
> > sources and locales support
> >
> > Hi, I'm trying to build the latest SDK sources - I need to use it in
> > Flash Builder and as mavenized artifacts.
> >
> > I noticed that, in the compiled and "IDEnized" SDK, the
> > {sdkhome}/frameworks/locale/... folders don't contain the *_rb.swc
> > files, with the exception of the en_US locale. Is this the intended
> > behavior? I see that the Adobe 4.6 SDK containes these compiled
> > resource bundles for all supported locales.
> >
> > In README, I read "The Apache Flex SDK defaults to using the en_US
> > locale and SDK error messages are by default displayed in American
> English".
> > Shouldn't the SDK, by default, include all the supported locales, or
> > am I misunderstanding the README?
> >
> > As a side note, I noticed this as a suspect while searching for the
> > cause of a "Could not find artifact
> > com.adobe.flash.framework:playerglobal:rb.swc:11.1" - seems that the
> > pom generated by the mavenizer references it (the
> > com.adobe.flex.framework.flex-framework pom), but the related artifact
> > was not generated nor deployed by the mavenizer tool.
> >
> > Any help? TIA
> >
>

RE: Building SDK from sources and locales support

[Frédéric THOMAS]

Maybe yes, know as well there are many other targets, run ant -p to get them 
all displayed and be sure to run the IDE script you need from the sdk/ide 
folder, I guess as well you will need to create the compiler locales as well if 
you're not US but I can't remember the ant build variable to set, maybe someone 
else remember otherwise look into the release target of the build.xml.

-Fred

-Message d'origine-
De : Cosma Colanicchia [mailto:cosma...@gmail.com] 
Envoyé : mardi 17 septembre 2013 17:52
À : dev@flex.apache.org
Objet : Re: Building SDK from sources and locales support

Thank you very much, running the other.locales ant target right now.. maybe we 
could drop a note about this in the README?


2013/9/17 Frédéric THOMAS 

> The locales are in and are well managed by the Maven converter / 
> deployer, use the SDK provided by the Installer or be sure you ran ant 
> -other.locale after a standard ant build from the sources to generate the 
> locales.
>
> -Fred
>
> -Message d'origine-
> De : Cosma Colanicchia [mailto:cosma...@gmail.com] Envoyé : mardi 17 
> septembre 2013 17:31 À : dev@flex.apache.org Objet : Building SDK from 
> sources and locales support
>
> Hi, I'm trying to build the latest SDK sources - I need to use it in 
> Flash Builder and as mavenized artifacts.
>
> I noticed that, in the compiled and "IDEnized" SDK, the 
> {sdkhome}/frameworks/locale/... folders don't contain the *_rb.swc 
> files, with the exception of the en_US locale. Is this the intended 
> behavior? I see that the Adobe 4.6 SDK containes these compiled 
> resource bundles for all supported locales.
>
> In README, I read "The Apache Flex SDK defaults to using the en_US 
> locale and SDK error messages are by default displayed in American English".
> Shouldn't the SDK, by default, include all the supported locales, or 
> am I misunderstanding the README?
>
> As a side note, I noticed this as a suspect while searching for the 
> cause of a "Could not find artifact 
> com.adobe.flash.framework:playerglobal:rb.swc:11.1" - seems that the 
> pom generated by the mavenizer references it (the 
> com.adobe.flex.framework.flex-framework pom), but the related artifact 
> was not generated nor deployed by the mavenizer tool.
>
> Any help? TIA
>

Re: Building SDK from sources and locales support

[Cosma Colanicchia]

Thank you very much, running the other.locales ant target right now.. maybe
we could drop a note about this in the README?


2013/9/17 Frédéric THOMAS 

> The locales are in and are well managed by the Maven converter / deployer,
> use the SDK provided by the Installer or be sure you ran ant -other.locale
> after a standard ant build from the sources to generate the locales.
>
> -Fred
>
> -Message d'origine-
> De : Cosma Colanicchia [mailto:cosma...@gmail.com]
> Envoyé : mardi 17 septembre 2013 17:31
> À : dev@flex.apache.org
> Objet : Building SDK from sources and locales support
>
> Hi, I'm trying to build the latest SDK sources - I need to use it in Flash
> Builder and as mavenized artifacts.
>
> I noticed that, in the compiled and "IDEnized" SDK, the
> {sdkhome}/frameworks/locale/... folders don't contain the *_rb.swc files,
> with the exception of the en_US locale. Is this the intended behavior? I
> see that the Adobe 4.6 SDK containes these compiled resource bundles for
> all supported locales.
>
> In README, I read "The Apache Flex SDK defaults to using the en_US locale
> and SDK error messages are by default displayed in American English".
> Shouldn't the SDK, by default, include all the supported locales, or am I
> misunderstanding the README?
>
> As a side note, I noticed this as a suspect while searching for the cause
> of a "Could not find artifact
> com.adobe.flash.framework:playerglobal:rb.swc:11.1" - seems that the pom
> generated by the mavenizer references it (the
> com.adobe.flex.framework.flex-framework pom), but the related artifact was
> not generated nor deployed by the mavenizer tool.
>
> Any help? TIA
>

Building SDK from sources and locales support

[Cosma Colanicchia]

Hi, I'm trying to build the latest SDK sources - I need to use it in Flash
Builder and as mavenized artifacts.

I noticed that, in the compiled and "IDEnized" SDK, the
{sdkhome}/frameworks/locale/... folders don't contain the *_rb.swc files,
with the exception of the en_US locale. Is this the intended behavior? I
see that the Adobe 4.6 SDK containes these compiled resource bundles for
all supported locales.

In README, I read "The Apache Flex SDK defaults to using the en_US locale
and SDK error messages are by default displayed in American English".
Shouldn't the SDK, by default, include all the supported locales, or am I
misunderstanding the README?

As a side note, I noticed this as a suspect while searching for the cause
of a "Could not find artifact
com.adobe.flash.framework:playerglobal:rb.swc:11.1" - seems that the pom
generated by the mavenizer references it (the
com.adobe.flex.framework.flex-framework pom), but the related artifact was
not generated nor deployed by the mavenizer tool.

Any help? TIA

Re: Build failed in Jenkins: flex-sdk_mustella #311

[Erik de Bruin]

> What would it take to have bad.png files stored somewhere so we don't have
> to use RDP to go look (and find they are not there because the next run
> has started)?

Time, mostly ;-) It's no problem to set this up, we can even provide
web access to Jenkins on the VM (like at builds@a.o.) and story the
'bad.png' files as 'artifacts'.

> Anyway, the focusColor test can fail is some other thing like an update
> warning on the machine takes focus away from the FP window.

Like me messing around on the VM... I'll try to be more 'hands-off' ;-)

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: Build failed in Jenkins: flex-sdk_mustella #311

[Erik de Bruin]

"Managers/StyleManager/SparkStyles/globalSelectors/GlobalStyles_mxmlOverride_tester
GlobalStyles_MxmlOverride_focusColor Failed CompareBitmap(body:step 4)
 compare returned[object BitmapData]"

Anyone have any idea why that may be failing? This is just the first
run in which it fails, so nobody panic, but if anyone made change that
may cause this, please re-check and re-test your code, just to be
safe.

Thanks,

EdB



On Tue, Sep 17, 2013 at 4:47 PM,   wrote:
> See 
>
> Changes:
>
> [jmclean] Update release notes
>
> [jmclean] FLEX-33728 added access to imageDecodingPolicy
>
> [jmclean] FLEX-33728 fixed so compiles and all supported version of flash and 
> chache first answer
>
> [jmclean] FLEX-33722 stop RTE when dragging a spark datagrid column
>
> --
> [...truncated 85871 lines...]
> shells:
>  [exec] next: pre_compile.sh 0
>  [exec] next: pre_compile.sh 1
>  [exec] next: pre_compile.sh 2
>  [exec] done with pre compile step
>  [java] exclude_filename: 
> C:/jenkins_slave/workspace/flex-sdk_mustella/mustella/tests/ExcludeListWin.txt
>  [java] os_version: ${os_version}
>  [java] target_os_name: windows
>  [java] device_name: ${device_name}
>  [java] result_include: -includes=SendResultsToRunner
>  [java] Choosing local runner bitmap save
>  [java] Choosing local runner bitmap save
>  [java] Choosing local runner bitmap save
>  [java] Choosing local runner bitmap save
>  [java] okey doke, going to compile 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\Managers\StyleManager\SparkStyles\SWFs\SparkStyles_Globals_mxml.mxml
>  [java] okey doke, going to compile 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\itemRenderers\Halo\List\SWFs\List_itemRendererTests.mxml
>  [java] okey doke, going to compile 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\containers\Accordion\SWFs\Accordion_InContainer_Spark.mxml
>  [java] okey doke, going to compile 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\resources\ResourceManager\SWFs\ResourceManagerApp.mxml
>  [java] Loading configuration file 
> C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
>  [java] Loading configuration file 
> C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
>  [java] Loading configuration file 
> C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
>  [java] Loading configuration file 
> C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
>  [java] 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\resources\ResourceManager\SWFs\ResourceManagerApp.swf
>  (737934 bytes)
>  [java] Choosing local runner bitmap save
>  [java] okey doke, going to compile 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\components\Application\SWFs\Application_Properties_App1.mxml
>  [java] Loading configuration file 
> C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
>  [java] 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\itemRenderers\Halo\List\SWFs\List_itemRendererTests.swf
>  (1185630 bytes)
>  [java] nothing left to do
>  [java] 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\containers\Accordion\SWFs\Accordion_InContainer_Spark.swf
>  (1449154 bytes)
>  [java] 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\Managers\StyleManager\SparkStyles\SWFs\SparkStyles_Globals_mxml.mxml(80):
>  Warning: The CSS type selector 'spark.components.TextArea' was not 
> processed, because the type was not used in the application.
>  [java]
>  [java] s|TextArea, s|Panel {
>  [java]
>  [java] 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\Managers\StyleManager\SparkStyles\SWFs\SparkStyles_Globals_mxml.swf
>  (2205119 bytes)
>  [java] All done with the compile
>  [java] leaving the compile, elapsed: 18
>  [java] ...via exit
>  [echo] compileswfs jreturn is 0
>  [loadfile] 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\local.properties 
> doesn't exist
>
> do_fail:
>
> compileswfs:
>
> getExcludes:
>
> getExcludeIds:
>
> populateExcludeTable:
>  [echo] populate exclude, got this for db time: 2013/09/17 09:45:56
>
> justrun:
>  [loadfile] 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\local.properties 
> doesn't exist
>
> delete_cache:
>  [echo] delete cache: /Users/ApacheFlex/Library/Caches/Adobe/Flash 
> Player/AssetCache
>  [loadfile] 
> C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\local.properties 
> doesn't exist
>
> delete_cache:
>  [echo] delete cache: /Users/ApacheFlex/AppData/Roaming/Adobe/Flash 
> Player/AssetCache
>[delete] Deleting directory 
> C:\Users\ApacheFlex\AppData\Roaming\Adobe\Flash Player\AssetCache\94ELK3V4
>[

Re: Build failed in Jenkins: flex-sdk_mustella #311

[Alex Harui]

What would it take to have bad.png files stored somewhere so we don't have
to use RDP to go look (and find they are not there because the next run
has started)?

Anyway, the focusColor test can fail is some other thing like an update
warning on the machine takes focus away from the FP window.

-Alex

On 9/17/13 7:55 AM, "Erik de Bruin"  wrote:

>"Managers/StyleManager/SparkStyles/globalSelectors/GlobalStyles_mxmlOverri
>de_tester
>GlobalStyles_MxmlOverride_focusColor Failed CompareBitmap(body:step 4)
> compare returned[object BitmapData]"
>
>Anyone have any idea why that may be failing? This is just the first
>run in which it fails, so nobody panic, but if anyone made change that
>may cause this, please re-check and re-test your code, just to be
>safe.
>
>Thanks,
>
>EdB
>
>
>
>On Tue, Sep 17, 2013 at 4:47 PM,   wrote:
>> See 
>>
>> Changes:
>>
>> [jmclean] Update release notes
>>
>> [jmclean] FLEX-33728 added access to imageDecodingPolicy
>>
>> [jmclean] FLEX-33728 fixed so compiles and all supported version of
>>flash and chache first answer
>>
>> [jmclean] FLEX-33722 stop RTE when dragging a spark datagrid column
>>
>> --
>> [...truncated 85871 lines...]
>> shells:
>>  [exec] next: pre_compile.sh 0
>>  [exec] next: pre_compile.sh 1
>>  [exec] next: pre_compile.sh 2
>>  [exec] done with pre compile step
>>  [java] exclude_filename:
>>C:/jenkins_slave/workspace/flex-sdk_mustella/mustella/tests/ExcludeListWi
>>n.txt
>>  [java] os_version: ${os_version}
>>  [java] target_os_name: windows
>>  [java] device_name: ${device_name}
>>  [java] result_include: -includes=SendResultsToRunner
>>  [java] Choosing local runner bitmap save
>>  [java] Choosing local runner bitmap save
>>  [java] Choosing local runner bitmap save
>>  [java] Choosing local runner bitmap save
>>  [java] okey doke, going to compile
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\Managers\Styl
>>eManager\SparkStyles\SWFs\SparkStyles_Globals_mxml.mxml
>>  [java] okey doke, going to compile
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\itemRenderers
>>\Halo\List\SWFs\List_itemRendererTests.mxml
>>  [java] okey doke, going to compile
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\containers\Ac
>>cordion\SWFs\Accordion_InContainer_Spark.mxml
>>  [java] okey doke, going to compile
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\resources\Res
>>ourceManager\SWFs\ResourceManagerApp.mxml
>>  [java] Loading configuration file
>>C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
>>  [java] Loading configuration file
>>C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
>>  [java] Loading configuration file
>>C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
>>  [java] Loading configuration file
>>C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
>>  [java]
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\resources\Res
>>ourceManager\SWFs\ResourceManagerApp.swf (737934 bytes)
>>  [java] Choosing local runner bitmap save
>>  [java] okey doke, going to compile
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\gumbo\compone
>>nts\Application\SWFs\Application_Properties_App1.mxml
>>  [java] Loading configuration file
>>C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
>>  [java]
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\itemRenderers
>>\Halo\List\SWFs\List_itemRendererTests.swf (1185630 bytes)
>>  [java] nothing left to do
>>  [java]
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\containers\Ac
>>cordion\SWFs\Accordion_InContainer_Spark.swf (1449154 bytes)
>>  [java]
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\Managers\Styl
>>eManager\SparkStyles\SWFs\SparkStyles_Globals_mxml.mxml(80): Warning:
>>The CSS type selector 'spark.components.TextArea' was not processed,
>>because the type was not used in the application.
>>  [java]
>>  [java] s|TextArea, s|Panel {
>>  [java]
>>  [java]
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\tests\Managers\Styl
>>eManager\SparkStyles\SWFs\SparkStyles_Globals_mxml.swf (2205119 bytes)
>>  [java] All done with the compile
>>  [java] leaving the compile, elapsed: 18
>>  [java] ...via exit
>>  [echo] compileswfs jreturn is 0
>>  [loadfile]
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\local.properties
>>doesn't exist
>>
>> do_fail:
>>
>> compileswfs:
>>
>> getExcludes:
>>
>> getExcludeIds:
>>
>> populateExcludeTable:
>>  [echo] populate exclude, got this for db time: 2013/09/17 09:45:56
>>
>> justrun:
>>  [loadfile]
>>C:\jenkins_slave\workspace\flex-sdk_mustella\mustella\local.properties
>>doesn't exist
>>
>> delete_cach

[FALCON] Should Falcon compile older SDKs?

[Alex Harui]

Falcon is catching subtle coding issues that MXMLC didn't catch like duplicate 
variable declarations, ambigous definitions and more.  Therefore, there is a 
good chance that when you compile an existing app with Falcon you might have to 
fix some of your code.  So far, I haven't seen anyone want to make Falcon less 
'strict'.

But I just ran into an issue with resource bundles where the current Falcon 
code reports a compile error if it can't find a bundle for a locale.  MXMLC 
seems to do some magic and makes the en_US bundle also act as the bundle for 
the locale that is missing a bundle.  It has to do that because the SDKs 
currently throw an error if a locale is missing a bundle.

But is that what we want?  I would think you should get a warning if a bundle 
is missing and the SDK should change its code so that if a bundle is missing it 
just falls through to the next bundle in the locale chain, if any.  But such a 
change would mean that, if you compile an existing project against an older 
SDK, even Apache Flex 4.10.0, your app may throw an error if you are missing a 
bundle.

Thoughts?
-Alex

Re: [Suggestion] CallOut and CalloutButton may add a modal:Boolean property.

[Carlos Velasco]

Yes, CalloutButton.


2013/9/17 Maurice Amsellem 

> AFAIK, Callout already has open(owner, modal) method.
>
> However CalloutButton calls open(this, false), which makes it always
> non-modal.
>
> So your suggestion is maybe only on CalloutButton ?
>
> Maurice
>
> -Message d'origine-
> De : Carlos Velasco [mailto:carlos.velasco.bla...@gmail.com]
> Envoyé : mardi 17 septembre 2013 12:31
> À : dev@flex.apache.org
> Objet : [Suggestion] CallOut and CalloutButton may add a modal:Boolean
> property.
>
> There are some cases where you may want your callout content to be modal;
> ie, not to be closed when clicking outside the callout content bounds. In
> that cases the component is desired to be closed programmatically or by
> clicking again the callout button.
>
> Adding such a property may not break the default component behaviour and
> would not generate so much complexity while it offers by default a new
> desirable behaviour.
>
> What do you think about?
>

Re: Dynamic validation in AS

[Franck Wolff]

Don't know if it could help, but you can check this:
http://www.graniteds.org/public/docs/3.0.0/docs/reference/flex/en-US/html/graniteds.validation.html

F.


2013/9/17 Oleg Konovalov 

> On Sep 16, 2013 7:36 PM, "Oleg Konovalov"  wrote:
>
> > Hi,
> >
> > I need to validate dynamic form data in Flex 4.5 ADG, meaning that I
> don't
> > know column names,
> > order, but if the attribute is Required, than I have to make sure user
> > filled it in.
> > From all examples I have seen, validations is done in MXML, but in my
> case
> > since data is dynamic, it should be done in AS.
> >
> > Any samples?
> >
> > Data comes dynamically to ADG,
> > but user can Add or Edit row in dynamically built Form.
> >
> > Please advise.
> >
> > TIA,
> > Oleg
> >
>

Re: Dynamic validation in AS

[Oleg Konovalov]

On Sep 16, 2013 7:36 PM, "Oleg Konovalov"  wrote:

> Hi,
>
> I need to validate dynamic form data in Flex 4.5 ADG, meaning that I don't
> know column names,
> order, but if the attribute is Required, than I have to make sure user
> filled it in.
> From all examples I have seen, validations is done in MXML, but in my case
> since data is dynamic, it should be done in AS.
>
> Any samples?
>
> Data comes dynamically to ADG,
> but user can Add or Edit row in dynamically built Form.
>
> Please advise.
>
> TIA,
> Oleg
>

Re: FlexUnit License

[Avi Kessner]

"He may be also able to provide a more recent version of Mockolate."

Wow, awesome!
These should definitely go in the release notes when we have a chance.

brought to you by the letters A, V, and I
and the number 47


On Tue, Sep 17, 2013 at 11:11 AM, Justin Mclean wrote:

> Hi,
>
> > Hamcrest looks like BSD, Mockolate looks like MIT.
>
> I spoke to Drew (developer of said libraries) and he confirmed:
> "Hamcrest-AS3 is BSD, same as Hamcrest for Java. Mockolate is MIT license.
> "
>
> He may be also able to provide a more recent version of Mockolate.
>
> Thanks,
> Justin
>

RE: [Suggestion] CallOut and CalloutButton may add a modal:Boolean property.

[Maurice Amsellem]

AFAIK, Callout already has open(owner, modal) method.

However CalloutButton calls open(this, false), which makes it always non-modal.

So your suggestion is maybe only on CalloutButton ?

Maurice

-Message d'origine-
De : Carlos Velasco [mailto:carlos.velasco.bla...@gmail.com] 
Envoyé : mardi 17 septembre 2013 12:31
À : dev@flex.apache.org
Objet : [Suggestion] CallOut and CalloutButton may add a modal:Boolean property.

There are some cases where you may want your callout content to be modal; ie, 
not to be closed when clicking outside the callout content bounds. In that 
cases the component is desired to be closed programmatically or by clicking 
again the callout button.

Adding such a property may not break the default component behaviour and would 
not generate so much complexity while it offers by default a new desirable 
behaviour.

What do you think about?

[Suggestion] CallOut and CalloutButton may add a modal:Boolean property.

[Carlos Velasco]

There are some cases where you may want your callout content to be modal;
ie, not to be closed when clicking outside the callout content bounds. In
that cases the component is desired to be closed programmatically or by
clicking again the callout button.

Adding such a property may not break the default component behaviour and
would not generate so much complexity while it offers by default a new
desirable behaviour.

What do you think about?

Re: migrating sdk

[Tom Chiverton]

On 17/09/2013 09:32, Miguel Ferreira wrote:

Without any more specification about where is the error occuring.

And you are sure you have the debug player ?

Do you maybe have a custom preloader or something ?

Are you compiling with RSL ? If so, turn that off for now. I'd also 
suggest you just go right to 4.10 unless you have a pressing reason for 
trying 4.6 first...


Tom

Re: Build failed in Jenkins: flex-sdk_release #184

[Erik de Bruin]

I just sent an email to builds@a.o., they have tendency to "improve"
the nodes with various tweaks. The 'release' and 'tlf' builds are also
failing due to reasons that seem unconnected to changes to the code...

EdB



On Tue, Sep 17, 2013 at 10:26 AM, Justin Mclean
 wrote:
> Hi,
>
> Anyone have any  idea why fixcrlf may be failing?
>
>> BUILD FAILED
>> :586: The 
>> following error occurred while executing this line:
>> :743: error 
>> running fixcrlf on file 
>> 
>
>
> Thanks,
> Justin



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

migrating sdk

[Miguel Ferreira]

VerifyError: Error #1014: Class spark.components.supportClasses::ItemRenderer 
could not be found.

Hi guys,
I am trying to migrate a version 4.1 to 4.6 then to migrate to 4.10.The project 
that i am working on was also migrate from 3.5 to 4.1 some years ago so maybe 
can have some dirty trash from that transaction.
My problem is the application runs well on the version 4.1 when i change the 
sdk and fix the errors and warnings i cannot open the application i get on the 
start directly the error:
VerifyError: Error #1014: Class spark.components.supportClasses::ItemRenderer 
could not be found.
Without any more specification about where is the error occuring.
I already tried to comment all the code and remove the dependencies to find 
where it come from but the error is always there...
Someone had something similar?
Thanks in advance!
Miguel

Re: Build failed in Jenkins: flex-sdk_release #184

[Justin Mclean]

Hi,

Anyone have any  idea why fixcrlf may be failing?

> BUILD FAILED
> :586: The 
> following error occurred while executing this line:
> :743: error 
> running fixcrlf on file 
> 


Thanks,
Justin

Re: FlexUnit License

[Justin Mclean]

Hi,

> Hamcrest looks like BSD, Mockolate looks like MIT. 

I spoke to Drew (developer of said libraries) and he confirmed:
"Hamcrest-AS3 is BSD, same as Hamcrest for Java. Mockolate is MIT license. "

He may be also able to provide a more recent version of Mockolate.

Thanks,
Justin