When _level0 becomes _level16384
Weird things happened in my Flash app recently, and to my surprise I realised that _level0 had become _level16384, apparently for no reason. I never even knew it was possible for _level0 to change level. At first I suspected it was another problem related to the getNextHighestDepth()-problem introduced by components, so I removed all usages of getNextHighestDepth(), which at first seemed to solve the problem. But then it reappeared. Some debugging revealed that incorrect usage of destroyObject has this interesting effect. What I found is that if you usedestroyObject(referenceToUIObject);
it is likely to change the level of _level0 and thus mess up your application. You need to use the instance name of the UIObject to destroy, as a String, like this:
destroyObject("nameOfUIObject");
... which in fact seems to work even though the instance is out of the scope of the function in which destroyObject is called. I also found that one can achieve this level-swapping on purpose using
_level0.swapDepths(0);
which also makes _level0 become _level16384. Weird...
posted by ballerina @ 6:17 pm
6 Comments:
og med det samme jeg er ute og nerder, legger inn et stalltips på at du mener 16384 og ikke 16834 til slutt der...
har slitt nok med akkurat det problemet, dog i andre språk. :)
Det hadde du jaggu rett i. Fikse... Jeg ante ikke at 16384-problemet var et velkjent fenomen! :)
:) stakkars da, det er sikkert ikke så nøye om du fikser. Det er ikke mange som er så miljøskadd som meg.
Det som skjer er at maskinen har satt av 14 bit minne til å lagre tallet. 14 bit har plass til lagre tallene mellom 0 og 16383, og så begynner den på null igjen når 16384 kommer, siden det er 2 opphøyd i 14.
Hehe, joda, jeg fikset nå helst med tanke på eventuelle google-søkende sjeler da. Jeg tror heller ikke det er veldig mange som instinktivt tenker at "16834 kan da umulig være riktig" når de leser noe sånt. :D
THANK YOU!!!!!
this had stumped me for the longest time ....
weird ...
Glad I could help! :-) It is weird yes, at least the things that seem to cause it. Esquil provided the logics of the number though, which is that the machine uses 14 bits to store the number. 14 bits can store numbers from 0 to 16383, and then it starts over again at 16384, since that is 2^14. But why e.g. the way in which destroyObject is called should affect it beats me...
Post a Comment
<< Home