Last week I had to write a small piece of code to send to a webservice a number from a text input. All was fine for the normal test values (0,1,100). The problem appeared when I tried to send the number -9223372036854775808. Instead of receiving this number I got -9223372036854776000. So I started to do some debugging I saw that the problem was in the soap functions from the Flex SDK when they did a number.toString().
I did a small test project to verify that the issue is with the toString() function. Here is the code:
<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" width="160" height="70"> <mx:Script> <![CDATA[ [Bindable] public var stringValue:String = "-9223372036854775808"; [Bindable] public var numberValue:Number = Number(stringValue); private function testToStringIssue():void { lbl.text = numberValue.toString(); } ]]> </mx:Script> <mx:Label x="10" y="10" text="{stringValue}" id="lbl"/> <mx:Button x="10" y="36" label="Button" click="testToStringIssue();"/> </mx:Application>
As you see we first display the stringValue and that is ok. Then we do a number toString() and display that result.
Tags: bug, flex, number, toString, webservice
This post was written by Virgil Cristea
Views: 1519
Articles
use int?
mabye some floating point error?
It’s not a bug per se, and the problem is not in the toString method. The problem is that the Number class uses 53 bits to store its values. ints and uints use 32 bits. The number you passed in would take more bits than that to represent. Just try this:
trace(-9223372036854775808);
You get the same result.
53 bits lets you accurately store numbers as large as 9007199254740992. You can store numbers larger than that, but at the expense of accuracy.
Int cannot store that value I needed. I do not think it is a floating point error as in debug I see the correct value set up in the numberVariable. The problem appears only when I do toString().
Same Problem here:
I get a Number from a Webservice: 371640000000009984
Make it to String and get: 371640000000010000
If I look at the Max_Value: 9223372036854775807 everything should be fine.
Other way around: a String: 371640000000009984 to a Number –> everything fine no “rounding” problem.
I look for a workaround (perhaps getting a String from the Webservice instead)….