[
https://issues.apache.org/jira/browse/FLEX-17210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14560570#comment-14560570
]
Chris Martin commented on FLEX-17210:
-------------------------------------
Okay spent some time looking into the original issue that was reported. To
recap, from what we can tell the user wanted to get back a formatted value when
using the zh-Hans locale, but didn't realize that they forgot to include the
resource when compiling their swf. At least this is the best assumptions we can
make without talking to the original filer.
I did some research on how to use the mx Formatters. It appears that when you
use them you are supposed to check the "error" property after you attempt to
format data [1]. So in this instance the user should have been checking
nf.error to see if it had a value. Because zh-Hans was not compiled in, the
decimalSeparatorTo is not set which results in an error message back. The
expected default value when running into a format error is "Invalid format".
However, even though it is a documented default, that default is never set in
the Formatter.as file. So unfortunately even if the user did check the nf.error
property, they would not get the expected default value. I think that this may
be the actual bug. If the user followed the recommended way of using the
Formatters, they would at least get "Invalid format" as their error message.
Side note, this can be overwritten by setting
Formatter.defaultInvalidFormatError.
Coincidentally the spark formatters would behave exactly as they described.
Not including the language resource in the compile does not result in an error.
The value is still formatted. Note though, that even with the spark formatter
they would still have to check the errorText property if they do not receive a
valid formatted value from the format function.
Overall I'm thinking that the behavior the filer reported is not a bug in the
SDK. The mx formatter did behave in the correct manner. The only bug is that
the error property didn't have the default value set, so if the filer attempted
to check it would return null. The filer's intended behavior of still receiving
a formatted value can be found by using the spark NumberFormatter
I think we should remove the exception throw and patch Formatter.as to make
sure the default value of "Invalid format" is set for the property,
defaultInvalidFormatError. I also suspect that the default for
defaultInvalidValueError would also need to be looked at.
I've made the changes in my environment and all 418 mustella tests for
ResourceManager. If all is well with these changes i'll also add in Mustella
tests for the bug where the default values for those properties were not being
returned.
[1]
http://help.adobe.com/en_US/flex/using/WS8b1c39bd7e9fc364-70b5c6d212c98ca85e2-7fff.html
> mx:NumberFormatter failed when use localeChain
> ----------------------------------------------
>
> Key: FLEX-17210
> URL: https://issues.apache.org/jira/browse/FLEX-17210
> Project: Apache Flex
> Issue Type: Bug
> Components: Formatters
> Affects Versions: Adobe Flex SDK Previous
> Environment: Affected OS(s): Windows
> Affected OS(s):
> Language Found: English
> Reporter: Adobe JIRA
> Assignee: Justin Mclean
> Labels: easytest
>
> Steps to reproduce:
> <?xml version="1.0" encoding="utf-8"?>
> <mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml";
> layout="absolute" creationComplete="onCC();">
> <mx:Script>
> <![CDATA[
> import mx.formatters.NumberFormatter;
>
> private function onCC():void
> {
> var nf:NumberFormatter = new NumberFormatter();
> nf.precision = 2;
> resourceManager.localeChain = ['zh-Hans'];
>
> trace("number:"+nf.format(1/3));
> resourceManager.localeChain = ['en_US'];
> trace("number:"+nf.format(1/3));
> }
> ]]
> >
> </mx:Script>
> </mx:WindowedApplication>
>
> Actual Results:
>
> number:
> number:0.33
>
> Expected Results:
>
> number:0.33
> number:0.33
>
> Workaround (if any):
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
