I noticed that the “did” show event does not fire with build 2014.2365.
I tested with two projects. The problem is that one project fires the event, while the other doesn’t.
Both projects run without issue with all previous builds up to and including 2014.2363.
It’s only build 2365 that exhibits this issue.
(Note: the “will” show event is fired)
Here are the differences between the two projects:
This project works:
main composer scene is displayed (will/did show events fire)
button is tapped to open new overlay (showOverlay). Overlay scene gets will/did show events.
This project doesn’t work:
main composer scene is displayed (will/did show events fire)
button is pressed to open new scene (gotoScene). New scene only fires “will” show event.
I found the issue!
I have a bunch of transitions in place (rotating, moving objects) in the main scene, so I have this in scene:hide:
function scene:hide(event) local sceneGroup = self.view local phase = event.phase local parent = event.parent if (phase == "will") then transition.cancel() end end
It looks like the changes you made to the transition library in 2365 caused a regression bug which cancels the scene transition as well.
Case number: 34032
I tried to get around this issue by specifying a tagname for the transitions only to find *another* bug :(.
Once a transition has been cancelled with a tagname, that tagname will not work anymore for new transitions.
(Case reported on another thread)
Today is “Find a bug Friday”! 
Having similar issues Can’t show my initial scene on launch. running in 1.0 compatibility I even use the new composer class
Hi guys,
This should be fixed in an upcoming daily, so please watch the build notes for this.
Thanks,
Brent
The issue that I reported (Case 34032) is fixed in build 2014.2370.
However, there’s still some weirdness going on when I call transition.to(…) after a transition.cancel() (canceling all active transitions).
I’m trying to isolate the issue so I can submit a new bug report.
I found the issue.
After a call to transition.cancel() (which cancels all transitions), any call to start a new transition in a composer scene’s show method’s “will” phase fails.
( Try saying *that* 10 times quick ;) )
Case 34162
In the mean time, I’ll revert back to 2014.2363 which works fine.
Here are the differences between the two projects:
This project works:
main composer scene is displayed (will/did show events fire)
button is tapped to open new overlay (showOverlay). Overlay scene gets will/did show events.
This project doesn’t work:
main composer scene is displayed (will/did show events fire)
button is pressed to open new scene (gotoScene). New scene only fires “will” show event.
I found the issue!
I have a bunch of transitions in place (rotating, moving objects) in the main scene, so I have this in scene:hide:
function scene:hide(event) local sceneGroup = self.view local phase = event.phase local parent = event.parent if (phase == "will") then transition.cancel() end end
It looks like the changes you made to the transition library in 2365 caused a regression bug which cancels the scene transition as well.
Case number: 34032
I tried to get around this issue by specifying a tagname for the transitions only to find *another* bug :(.
Once a transition has been cancelled with a tagname, that tagname will not work anymore for new transitions.
(Case reported on another thread)
Today is “Find a bug Friday”!
Having similar issues Can’t show my initial scene on launch. running in 1.0 compatibility I even use the new composer class
Hi guys,
This should be fixed in an upcoming daily, so please watch the build notes for this.
Thanks,
Brent
The issue that I reported (Case 34032) is fixed in build 2014.2370.
However, there’s still some weirdness going on when I call transition.to(…) after a transition.cancel() (canceling all active transitions).
I’m trying to isolate the issue so I can submit a new bug report.
I found the issue.
After a call to transition.cancel() (which cancels all transitions), any call to start a new transition in a composer scene’s show method’s “will” phase fails.
( Try saying *that* 10 times quick ;) )
Case 34162
In the mean time, I’ll revert back to 2014.2363 which works fine.