"The transition.cancel() function will cancel one of the following, depending on the passed parameter:
When using “transition.cancel()” in this fashion, does automatically nil out all the transitions?
Hi @mort,
If you didn’t assign them to variables/holders, it should remove them from memory. Are you seeing otherwise, memory-wise?
Thanks,
Brent
I haven’t tested the newer method yet, I was asking out of curiosity, as I remember how, way back when, display.remove() was enhanced, such that removing the group and niling it out was enough to take care of everything within! I was hoping that was the case with this implementation.
In the documentation, it assigns the example transitions to local variables, but does not specify that it’s necessary to nil said variables upon transition.cancel(). Many people may assume that it’s not necessary to nil anything out anymore, even when variables/holders are present.
So, you’re saying that all transitions (including those with handles) are cancelled, but one must still manually nil out all handles?
I’m considering not assigning variables to transitions, and just using the “tag” or “object name” method to cancel them. It appears to work. I’m trying to avoid having to loop through a table or group just to cancel transitions. Is this safe? (Is transition.to without a handle localized to the module?)
I think I have a solution, please verify.
--In sceneCreate: local myobj = display.newRect(sceneGroup, 75, 75, 150, 150) ... --later on, I add the transition as a property of the object: myobj.trans = transition.to( myRectangle, { time=1000, alpha=0} ) --Before I exit the scene or remove the object, etc., I call: transition.cancel() or transition.cancel(myobj)
Then, when the scene’s view is destroyed (when composer removes the sceneGroup), shouldn’t myobj.trans automatically be set to nil?
Any ideas? I’m not trying to be a pest, but I’m really keen on using the new system 
!
Hi @mort,
Sorry for the delay. If you assign the transition to a variable or a property of an object (myobj.trans), it’s probably safer to manually nil out that value (although if you are destroying the object anyway, its properties should be destroyed with it, so you’ll probably be OK).
If you don’t assign the transition to a variable, canceling it will make it eligible for Lua garbage collection.
Brent
@ Brent,
Never a problem. We’re all very busy people! I always try to wait at least a few days before bumping a thread.
Yeah, I remember you mentioning that properties on an object are “nil’d” out upon destruction, so I’ll go with that route (removing and “niling” out a display group (which auto-removes and “nils” out its children), or allowing composer to do that for me, through the sceneGroup).
Alright, so I’m assuming transitions and timers alike, when anonymous, are localized to the module through the object. That is, unless one explicitly declares either with a global variable?
Thanks for your help! I can’t wait until there is an equivalent functionality for “timer.cancel”.
Hi @mort,
Yes, if you make them anonymous, they are “part of the respective library”, and when you cancel them, they are cleaned out from there. It’s only if you assign them to a variable somewhere and forget to nil that reference out (or don’t destroy the object its part of) will it potentially remain locked in memory and cause a leak.
Brent
Alright, so I was on the correct track, thanks for clarifying that for me!
That actually answers another general question of mine regarding something like display.setStatusBar(), where I was unclear on whether it required a local variable.
Yes, I know it’s a more general function, and has nothing to do with display.remove(), but it’s always good to be through. That’s one of the frustrating things about localizing, it’s not always clear (outside of functions, standard display objects, audio, when one needs to access timers or transitions directly, and modules!)
Hi @mort,
If you didn’t assign them to variables/holders, it should remove them from memory. Are you seeing otherwise, memory-wise?
Thanks,
Brent
I haven’t tested the newer method yet, I was asking out of curiosity, as I remember how, way back when, display.remove() was enhanced, such that removing the group and niling it out was enough to take care of everything within! I was hoping that was the case with this implementation.
In the documentation, it assigns the example transitions to local variables, but does not specify that it’s necessary to nil said variables upon transition.cancel(). Many people may assume that it’s not necessary to nil anything out anymore, even when variables/holders are present.
So, you’re saying that all transitions (including those with handles) are cancelled, but one must still manually nil out all handles?
I’m considering not assigning variables to transitions, and just using the “tag” or “object name” method to cancel them. It appears to work. I’m trying to avoid having to loop through a table or group just to cancel transitions. Is this safe? (Is transition.to without a handle localized to the module?)
I think I have a solution, please verify.
--In sceneCreate: local myobj = display.newRect(sceneGroup, 75, 75, 150, 150) ... --later on, I add the transition as a property of the object: myobj.trans = transition.to( myRectangle, { time=1000, alpha=0} ) --Before I exit the scene or remove the object, etc., I call: transition.cancel() or transition.cancel(myobj)
Then, when the scene’s view is destroyed (when composer removes the sceneGroup), shouldn’t myobj.trans automatically be set to nil?
Any ideas? I’m not trying to be a pest, but I’m really keen on using the new system !
Hi @mort,
Sorry for the delay. If you assign the transition to a variable or a property of an object (myobj.trans), it’s probably safer to manually nil out that value (although if you are destroying the object anyway, its properties should be destroyed with it, so you’ll probably be OK).
If you don’t assign the transition to a variable, canceling it will make it eligible for Lua garbage collection.
Brent
@ Brent,
Never a problem. We’re all very busy people! I always try to wait at least a few days before bumping a thread.
Yeah, I remember you mentioning that properties on an object are “nil’d” out upon destruction, so I’ll go with that route (removing and “niling” out a display group (which auto-removes and “nils” out its children), or allowing composer to do that for me, through the sceneGroup).
Alright, so I’m assuming transitions and timers alike, when anonymous, are localized to the module through the object. That is, unless one explicitly declares either with a global variable?
Thanks for your help! I can’t wait until there is an equivalent functionality for “timer.cancel”.
Hi @mort,
Yes, if you make them anonymous, they are “part of the respective library”, and when you cancel them, they are cleaned out from there. It’s only if you assign them to a variable somewhere and forget to nil that reference out (or don’t destroy the object its part of) will it potentially remain locked in memory and cause a leak.
Brent
Alright, so I was on the correct track, thanks for clarifying that for me!
That actually answers another general question of mine regarding something like display.setStatusBar(), where I was unclear on whether it required a local variable.
Yes, I know it’s a more general function, and has nothing to do with display.remove(), but it’s always good to be through. That’s one of the frustrating things about localizing, it’s not always clear (outside of functions, standard display objects, audio, when one needs to access timers or transitions directly, and modules!)