Bug #1581

By dumganhar Posted 2012-11-28 14:04

Some fixes of JSBinding codes:
* [1] Check whether the proxy was already added in JS_NEW_PROXY
* [2] In struct schedFunc_proxy_t, JSScheduleWrapper* --> CCArray*
Reason: One js function may correspond to many targets. To debug this, you could refer to JSScheduleWrapper::dump function. It will prove that i'm right. :)
* [3] In ScriptingCore::cleanupSchedulesAndActions function, we must invoke unschedule for all targets and remove the proxy both in *_schedFunc_target_ht* and *_schedTarget_native_ht*, otherwise the hash tables will grow bigger and bigger, so I added a new function *JSScheduleWrapper::removeAllTargetsForNatiaveNode* to make this things easier.
* [4] To easily find out the bugs of binding codes, I add *JS_SetGCZeal* in *ScriptingCore::createGlobalContext*, it only works in DEBUG mode.
* [5] In *js_cocos2dx_CCNode_getChildren*, we should add the generated array to root to avoid gc happen when invoking *JS_SetElement*.
* [6] The JSCallFuncWrapper isn't needed since an action will be run by a cc.Node and it will be released at the CCNode::cleanup.
* [7] Some improvements of *JSScheduleWrapper* class.
* [8] Added a new function *JSScheduleWrapper::setTarget*, it's for *js_CCNode_unschedule* to find out which target need to be unscheduled.
* [9] Commented *JS_SetReservedSlot* in *js_CCNode_scheduleOnce* and *js_CCNode_schedule*.
Reason:
For js_CCNode_scheduleOnce: Don't add the callback function to the reserved slot of this js object.Since the class of js object may be inherited from cocos class(e.g. cc.Sprite). The subclass will not contain reserved slots. It will crash if invoking this.
For js_CCNode_schedule: Don't add js callback function to the reserved slot of scheduler js object. Since the scheduler is an object always rooted.
So the callback function might not be released when gc comes.I looked inside the implementation of cc.Node.schedule, and it doesn't use JS_SetReservedSlot there.

Back