Also, it seems to only happen when using a tag.
This works as expected:
local testText = display.newText("TESTING...", display.contentCenterX, display.contentCenterY, native.systemFont, 18) local trans = transition.to(testText, {time=3000, alpha=0, tag="test"}) print("Attempting to cancel the transition") transition.cancel(trans)
Is there a way to edit a reported bug?
Thanks,
Dave
Dave, I just tested your initial transition code with the tag on one of my dev machines, and it seemed to work as normal. Meaning, the transition was canceled. I’m using Win 7 64 bit with Corona 2015.2692.
I just now tested your transition variable cancellation as well, and that works for me too. I’m going to move up to another daily build shortly and report back if I see anything different.
@Alex, thanks for testing!
We noticed the problem initially on 2697, then I had gone back to 2687 and couldn’t reproduce it in our code.
So I created the simple example above to prove it, but I didn’t realize I was still on 2687. Strangely, the problem exists there. Switching back to 2697 (the one we initially had trouble with), transition.cancel is working as expected… So I’m perplexed.
I think maybe the transition.cancel(tagName) just needs someone to take a look at it and verify it’s working properly.
Thanks,
Dave
[I deleted my last post as there was actually an issue with it that I am resolving now. It’s what I get for trying to clean it up and then insufficiently testing my cleanup before posting…]
Noted! I’ll do my best to give it a go when you get some code up.
I’m still looking into this. I cannot seem to reproduce it on demand. Code that previously worked in our app has started failing, and in the process of trying to prove it, I found the transition cancel bug that’s already been fixed, but can’t prove the problem that our app now has. 
I can’t figure out what the magic combination is… I thought I had it figured out yesterday. I thought it was related to canceling a transition inside an object’s removeSelf, but then my contrived example (that I posted here, then deleted) had some other issues that was causing it to fail besides what I was trying to prove.
I’m going to spend a little bit more time on it this morning before throwing in the towel. Essentially I can fix my problem by just wrapping some code like so:
if menuGroup ~= nil then menuGroup.isVisible = false end
But what bothers me is that I don’t see any reason for that code (inside a transition’s onComplete) to ever fire… It should have been canceled, and I debugged, stepping through, and I see it start the transition, then I see it call transition.cancel on it a little later, and then the onComplete happens. It’s blowing my mind.
I’m wondering if something is somehow detaching the transition from whatever table/array they’re stored in, and then the transition.cancel(tagName) just doesn’t see it. But I can’t figure out what would be doing that.
Dave
Okay, I think I’m onto something. I don’t know exactly what is causing the problem, but I can finally reproduce it. I’ve been trying to make the example more concise, but I can’t seem to. This seems to be the magic combination.
local widget = require( "widget" ) local composer = require( "composer" ) composer.recycleOnSceneChange = true local scene = composer.newScene() local rect local scrollView local function removeObjectAndCancelTransition() print("-- Removing rect, which affects the scrollView group") display.remove(rect) rect = nil print("-- Should be cancelling transTag transition") transition.cancel("transTag") end -- "scene:create()" function scene:create( event ) local sceneGroup = self.view local group = display.newGroup() scrollView = widget.newScrollView { top = 0, left = 0, width = display.contentWidth, height = display.contentHeight, scrollWidth = display.contentWidth, scrollHeight = display.contentHeight, horizontalScrollDisabled = true, friction = .99, -- how fast the content travels when flicked; default is 0.972 backgroundColor = {0, 0, 0}, hideScrollBar = true } rect = display.newRect(0,0,100,100) rect:setFillColor(1,0,0,1) transition.to(rect, { time = 1500, x = 100, transition = easing.outExpo, tag = "transTag", onComplete = function() print("\*\*\* WRONG: Transition COMPLETED, but it should be CANCELLED! \*\*\*") end, onCancel = function() print("\*\*\* RIGHT: Transaction CANCELLED, as expected \*\*\*") end }) scrollView:insert(rect) group:insert(scrollView) -- Using a timer here so that the scene will be created properly before we attempt to destroy it. timer.performWithDelay(100, function() -- change the value of cancelAsExpected to see the difference. local cancelAsExpected = false if cancelAsExpected then -- this cancels the transition as expected composer.removeScene("scene1") else -- this does not cancel the transition composer.gotoScene("scene2", options) end end) end -- "scene:destroy()" function scene:destroy( event ) print("-- destroying scene1 --") local sceneGroup = self.view removeObjectAndCancelTransition() end -- ------------------------------------------------------------------------------- -- Unimportant stuff -- ------------------------------------------------------------------------------- -- "scene:show()" function scene:show( event ) end -- "scene:hide()" function scene:hide( event ) end -- Listener setup scene:addEventListener( "create", scene ) scene:addEventListener( "show", scene ) scene:addEventListener( "hide", scene ) scene:addEventListener( "destroy", scene ) -- ------------------------------------------------------------------------------- return scene
Both composer.removeScene and composer.gotoScene will call the destroy method in that example. However, the gotoScene version will not cancel the transition properly.
Thanks,
Dave
Note that the only way I can get it to fail is by having an item inserted into a scrollView, then display.removed… And I can only get it to break using composer.gotoScene.
It’s a fairly complicated combination, but it worked properly back in 2687, but not in 2697.
Thanks,
Dave
Thanks Dave, we’ll look into it. Note that the work-around for now is to cancel the transition before removing the object. Change remvoeObjectAndCancelTransition to this, and your sample works as expected:
[lua]local function removeObjectAndCancelTransition()
print("-- Should be cancelling transTag transition")
transition.cancel(“transTag”)
print("-- Removing rect, which affects the scrollView group")
display.remove(rect)
rect = nil
end[/lua]
Thanks, Michael. It’s unfortunately much more complicated than that in my actual app, which is why it took me about 3 days to figure out how to reproduce it in a simpler example.
Dave
Hi guys,
Just to add another voice to this, I’ve also found that in daily builds >2687 all kinds of weirdness has crept into my project and I’m fairly certain it’s related to transition.cancel no longer working. Unfortunately I can’t give you a clearer example, as like Dave my transitions are buried in a complex mess of code. I’m on OSX and the issues are prevalent in both the simulator and iOS device builds.
Many thanks,
Andrzej
// Futuretro Studios
In fact my problems with transitions began at precisely 2692. Everything was fine up to 2690 inclusive, and has remained broken including the latest (2722). I’ll see if I can’t provide some more substantial feedback when I get the chance.
Andrzej
The problem tracking down this bug, is that everything works fine for a few minutes then it all goes sideways… like a heap that is being
blown away…
I ran into issues with the transition library after upgrading to 2692. The problem for me was calling transition.cancel for a transition that was already cancelled/nil. Changing that fixed all my issues with transitions.
I don’t call transition.cancel the problem still happens.