Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
reinierf

TweenLite.killDelayedCallsTo works unexpected for multiple instances of the same prototype

Recommended Posts

When calling TweenLite.killDelayedCallsTo on a method of an object, all objects with the same prototype will have there delayed calls to that method killed.

 

Cause:

When no scope is bound to the method, the method is really the same function object shared by all instances of the prototype. So they will all be killed by 1 call.

 

Solution:

Bind your callbacks using .bind(this) or use a closure and place the bound function/closure in a variable.

Then, later you can call TweenLite.killDelayedCallsTo on the bound callback.

 

A second argument in TweenLite.killDelayedCallsTo for specifying scope would also be nice, just like with the onCompleteScope etc in TweenLite.to/.from.

That would save us a lot of binding and storing functions, and would be in line with the other static TweenLite methods.

Link to post
Share on other sites

Interesting dilemma. I'll chew on that. In the mean time, I suspect you could accomplish it like this:

function killCallsTo(func, scope) {
    var calls = TweenLite.getTweensOf(func);
    for (var i = 0; i < calls.length; i++) {
        if (calls[i].vars.onCompleteScope === scope || calls[i].vars.callbackScope === scope) {
            calls[i].kill();
        }
    }
}

Does that work for you? 

Link to post
Share on other sites

Is there something on your roadmap to implement a scope-argument (optional) to the killDelayedCallsTo? Finally it was easy to fix some "strange" behaviors in my game, after realizing the problem with the scope. But until that, it took me some time :)

 

BTW: The above example works great, but you need to use callbackScope instead of onCompleteScope.

Link to post
Share on other sites

Good feedback - I updated the demo code above to include callbackScope as well. 

 

No plans to add this to the core toolset at this point (mostly due to wanting to protect file size and it not being a very common request at all and the fact that it's relatively easy to work around with the code above), but if we do get more requests for it we'll certainly reconsider. Thanks again for the feedback.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×