Related Posts (generated):

• Scientific Notation Patch Accepted
• Let’s patch: Fun with Scientific Notation!
• ObjectUtil.compare() Patch attempt number 2
• Hold the HTTPService: Flex 3.4 gets a showstopper
• ObjectUtil.compare() Patch 3 (with feeling!)

I removed the Bug Quash badge since it’s misreporting, but this is my fourth patch accepted. I was hoping for 5, but if you followed the Bug Hunting series, my big fix for object comparisons was accepted with some caveats, meaning I didn’t get credit.

The 4 month delay is obviously due to the push for Flex 4. Though the trunk is somewhat off limits to community patches depending on your reading of the Submitting a Patch page on Adobe’s site. “We are starting Flex 4 development in /flex/sdk/trunk, so the trunk is in flux and patches submitted against it are less likely to be accepted for now.”

Related Posts (generated):

• Let’s patch: Fun with Scientific Notation!
• ObjectUtil.compare() Patch attempt number 2
• Hold the HTTPService: Flex 3.4 gets a showstopper
• ObjectUtil.compare() Patch 3 (with feeling!)
• Bug hunting in the Flex SDK (part 3)

If you add a responder to a token created by the send() method, you’ll end up with two calls to the responder for every return by the server. The workaround is use event listeners rather than responders, but a lot of people (myself included) aren’t interested in rewriting legacy code to work around something that worked in a prior version.

Related Posts (generated):

• Scientific Notation Patch Accepted
• Let’s patch: Fun with Scientific Notation!
• ObjectUtil.compare() Patch attempt number 2
• Flex 3.5 finally released
• HTTPService bug crushed in 3.x branch

The problem lies with Scientific Notation and it’s formatting when converted to string using NumberFormatter, which doesn’t take into account the altered decimal position. Since we’re dealing with strings in the function itself, flex doesn’t have to worry about the size of the number, so I simply built the number up to full size and send it down the line. The same problem was in the NumberBase class when adding the thousands separator via formatThousands since it converts the Object->Number->String which returns my fancy long string to scientific notation. Since I’d already solved the problem, I just copied some code over. Both places needed to be fixed because only the numbers to the right of the decimal are sent to the formatThousands function.

I also learned that when talking precision, flex means number of decimal places, not significant digits. A major distinction mentioned in the NumberBase reference.

So what about the “expected result”? Well the value being formatted is -2.34444444444434e+21 which expands out to -2,344,444,444,444,340,000,000. The expected result is listed as -2,344,444,440,000,000,000,000 for some reason. I assume it’s someone’s calculator rounding off to a numerical precision of 9 since the actual value of 235345-242+99209323-2344444444444444444444 is -2344444444444345000018 which also tells me that flex’s default numerical precision is 15.

My patch is SDK-22643 if you’re interested.

Related Posts (generated):

• ObjectUtil.compare() Patch attempt number 2
• Hold the HTTPService: Flex 3.4 gets a showstopper
• ObjectUtil.compare() Patch 3 (with feeling!)
• Bug hunting in the Flex SDK (part 3)
• Bug hunting in the Flex SDK (part 2)

Let’s not do String comparisons…that’s too slow. Let’s build up a better dictionary mapping equal objects to equal objects (or equal to unequal ones). That would be the correct fix here.

Which is also a point I mentioned when I submitted the patch. There is another way to fix the bug, but rather than the laser surgery, I have to go in with a scalpel. This time I’m altering a few function’s arguments. All the functions are private, but it’s something I’d rather avoid.

I tried mirroring the functionality of the string function I used, but without having to deal with strings. What made this work so well was the resetting of object ids every time you built the string. That’s not an option here because we don’t want to lose the generic object IDs.

My original thought of a fix was to pass a list of objects that are parents of the object is probably the best option. I finally defaulted back to this, but ran into another problem with Flex. You cannot pass by reference. I tried the ObjectUtil.copy() function, but it doesn’t work with dictionaries (SDK-13787). That meant I had to perform the copy within the compare function. It’s not perfect, but when dealing with infinite recursion not much is. I looked into altering the copy function, but I didn’t see a way to determine if a dictionary was using weak references.

The new patch is at SDK-22552

Related Posts (generated):

• Hold the HTTPService: Flex 3.4 gets a showstopper
• ObjectUtil.compare() Patch 3 (with feeling!)
• Bug hunting in the Flex SDK (part 3)
• Bug hunting in the Flex SDK (part 2)
• Bug Quash