|
Big update to the still new digging system already.
I think I fixed the issue with some Knuffel that would always produce a "Invalid KID" error (KID stands for Knuffel ID, as you may have guessed). I had to rebuild most of the communication code to fix it, and I built a mode to assume other user's IDs in the digging page for debugging this, and in the process created a lot of other bugs I had to fix...
But on the other hand, I also got the SWF optimization issue done, meaning the SWF file is considerably smaller now and shouldn't take a lot less time to load.
You may all have to manually reload the Digging page next time you try to use it, but the new code is working better at least on my machine. Please go and give it a try.
For the seemingly unprobable case of having other newbie flex coders in the community out there interested in the details of the problem and the solution, for it was an issue with ActionScript/Flex I had to do rather long and tiresome research to solve:
The problem was caused by the automatic result handling done by the HTTPService class. The default result handling mode tries to convert XML response to an AS Object, which allows for named variable returns accessed as object properties, very nice indeed on first glance. The catch was that AS tries to be smart when interpreting the returned XML CDATA and won't let you choose the type casting it does, meaning: Strings that could be interpreted as numbers are interpreted as numbers, and there's no way of preventing this behaviour.
Now we have a new type of Knuffel IDs with the new Knuffel, which is an 8-character string representing an 8-digit hexadecimal number, and AS typecasting didn't recognize this in most cases, which is why it seemed to work well at first glance. The problem was with IDs which consisted of decimal digits and a single digit E: For instance, "1943E021" was read as scientific notation number and converted to 1.943*10^24, and the toString() returned "1.943e+24" accordingly.
Sadly, the only solution I could find is to use the result type e4x, which treats the result as an XML Object. Which has to be treated somewhat differently when using the result object, which is why I had to rewrite most of my communications code (well, at least the result handling part). I didn't try, but I'd almost assume that FlashVars would do similar typecasting on this kind of result. To conclude this whole issue, the lesson learnt is this: Never use the default result type of object with the HTTPService class.
 (0)  (0) |
|
