flex-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Martin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLEX-17210) mx:NumberFormatter failed when use localeChain
Date Wed, 27 May 2015 07:38:18 GMT

    [ 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"
> 	<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

View raw message