> This bug is fixed in SVN. You can apply the attached patch to your > checkout / download to fix this in your qooxdoo version, too.
I don't think it is fixed - though I see that you picked up on another implication of it, that the wrong entry was cleared from the _db array when disposing. You still use qx.Class._db as the reference array of all objects. However, an object will be omitted from the array if vAutoDispose is set to false, so for those objects you will never be able to find them from the hash code. And then, if you have an object which is added *after* one with vAutoDispose set to false, its index in the _db array *does* *not* *correspond* with the value of this._hashCode. Therefore the call to fromHashCode will return the wrong object, as it depends on the index into the _db array being the same as the hash code. To illustrate: Object vAutoDispose Hashcode _db A true 0 [A] B true 1 [A, B] C false 2 [A, B] D true 3 [A, B, D] E true 4 [A, B, D, E] Now, qx.Object.fromHashCode(D.toHashCode) returns E. qx.Object.fromHashCode(C.toHashCode) returns D. I also see that you've left the class toHashCode function untouched. So again, if you call this function with an object which is not derived from qx.object, it will allocate a hash code to it but won't remember it in the _db array. If you never intend a non-qx.object parameter being passed to the function, I suggest you get rid of the code to test for the existence of the hashCode member, and just return o.hashCode directly. Hugh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
