The problems I’m seeing are apparent when using the app, so as long as your testing doesn’t show any problems I think you’re OK. Honestly I have yet to find out what the actual problems are. Some of my composer scenes are OK, some are not.
Like I’ve said above: Life was good up to build 2363. It’s very late here now and I need to get some sleep. I’m going to tackle this in the morning.
Thank you, Ingemar. It’s reassuring.
A new bug I found (or it could’ve been there for a while but I didn’t see it until a couple days ago) was with starting a transition after transition.cancel was called. So I added a timer delay for the transition that needs to start immediately after transition.cancel, which fixed it for me. Otherwise, I haven’t seen any issues so far.
Composer scene changes have been working as expected for me.
I’ll test some more today without developer-rejecting my submission.
Thanks again.
Naomi
A new bug I found (or it could’ve been there for a while but I didn’t see it until a couple days ago) was with starting a transition after transition.cancel was called. So I added a timer delay for the transition that needs to start immediately after transition.cancel, which fixed it for me.
That behavior started with build 2365 and is consistent with my testing. I think it’s related to the issue I have where I have to put a gotoScene in a timer.performWithDelay() for my transitions to work in the new scene.
(I’m going to publish my findings on this thread as they become available)
Issue 1:
I’ve found that the fix for 34033 doesn’t fully fix the tagname re-use issue. This is similar to the outstanding bug report I have reported above (34162).
I have several scenes with background elements that are the same. The elements have the same tagname in all scenes. I use transition.cancel(tagname) in the “will hide” event from one scene and a transition.to(…tag=tagname) in the “will show” event in the next scene. What happens is that the animations fail to start in the new scene.
There are 2 workarounds for this issue:
Use a separate tag-name in the second scene
In the second scene, issue the transition.to() call within a timer.performWithDelay(). The delay must be at least 2 to work.
Thank you, Ingemar, for the details.
It sounds like the timer.performWithDelay() that I used to fix my problem probably solved other potential problems that could’ve given me headache with the 2014.2370 build. Thank goodness, it sounds like I can let it stay for now. Whew, a sigh of relief. (Releasing a build is never ever smooth, is it?)
Thanks again. I really appreciate your thorough approach to testing & investigating issues.
Naomi
P.S. BTW, for good measure, I gave it 100 for the timer.performWithDelay() when I implemented my workaround. 
ingemar,
Just letting you know that i’m looking into the remaining issues you found.
Thanks,
alex
Thanks, much appreciated !
Issue 2:
There seems to be some “cancellation memory” going on as well.
I’ve noticed when I issue a transition.cancel(object) that the next time I call transition.to() for that same object the cancel event is immediately fired. However if I (for example) cancel the transitions for 6 objects, only the last object will get the cancel event called when a new transition is put on it.
I tested this by adding an onCancel event for all my transitions to see what was going on.
This one is tricky, and I haven’t nailed it down perfectly yet, however I’ve had success with a potential workaround.
I’ll need to do some more testing to completely understand what’s going on before I can tackle creating a bug report…
Potential Workaround:
Assign the transition handle to a property and do the cancel on the property. i.e.
-- this can sometimes cause issues function object:reset() transition.cancel(self) end . self:reset() . transition.to(self, ...) . . some code . self:reset() . . some code (can take several seconds to execute) . transition.to(self, ...) -- will not start the new transition on the object -- workaround function object:reset() if (self.transHandle) then transition.cancel(self.transHandle) end end . self:reset() . self.transHandle = transition.to(self, ...) . . some code . self:reset() . . some code (several seconds) . transition.to(self, ...) -- will start the transitionGood news.
It looks like all of the weirdness I’ve been seeing has been narrowed down to a combination of the issues I’ve reported above.
I was able to get my troublesome project running with build 2373 with the workarounds I mentioned. I still need to create a bug report for the last issue I mentioned above, hopefully I’ll be able to recreate it in a simple project.
Phew… first time it’s taken me this long to figure things out. (where did the weekend go :wacko:???)
I filed a bug report (Case 34276) for the issue with transition.cancel() acting strangely when you supply the variable for a display object as the argument. I didn’t discover this thread until afterwards, so it would seem that the problem is larger in scope than I originally thought. Anyways, here’s the description I gave in my bug report:
Starting with daily build # 2014.2365, calling transition.cancel() with a display object as the sole argument results in unwanted behavior. The transition successfully cancels, but future attempts to perform a transition to that display object are unsuccessful, with no error outputted to the terminal. I have confirmed that this bug first presented itself in daily build # 2014.2365, up to and including the most recent daily build as of today (#2014.2373). Using transition.cancel() while supplying a handle or tag instead of a display object as the argument works as expected in my testing - this issue seems to be isolated to cases where you supply the a display object’s variable as the argument.
See the attached main.lua, which has buttons to perform the following:
1.) start a transition on the rectangle in the center of the screen
2.) cancel that transition, supplying the rectangle’s variable as the sole argument to transition.cancel()
3.) re-start the transition.
4.) repeat steps 2 & 3 as often as you want.
Using daily build # 2014.2365 or earlier, this little program works as you’d expect. But starting with build # 2014.2365, step 3 above does not work.
And here is the main.lua file I supplied as a test case:
------------------------------------------------------------------------------------ -- REQUIRE WIDGET LIBRARY ------------------------------------------------------------------------------------ local widget = require("widget") ------------------------------------------------------------------------------------ -- DELARE POSITIONING VARIABLES ------------------------------------------------------------------------------------ local centerX = display.contentCenterX local centerY = display.contentCenterY local screenTop = display.screenOriginY local screenLeft = display.screenOriginX local screenBottom = display.screenOriginY+(display.contentHeight-(display.screenOriginY\*2)) local screenRight = display.screenOriginX+(display.contentWidth-(display.screenOriginX\*2)) local screenWidth = screenRight - screenLeft local screenHeight = screenBottom - screenTop ------------------------------------------------------------------------------------ -- FORWARD DELARE VARIABLES ------------------------------------------------------------------------------------ local rect, goTrans, buttonPress, button1, button2, button3 function goTrans() local targetY = centerY - screenHeight\*.25 if rect.y ~= centerY then targetY = centerY end transition.to(rect, {y = targetY, transition = easing.inOutSine, onComplete = goTrans}) end rect = display.newRect(centerX, centerY, screenWidth\*.25, screenWidth\*.25) function buttonPress(event) local target = event.target if target.pressed == nil then target.pressed = true transition.to(target, {alpha = 0, y = screenBottom}) if target == button1 then goTrans() transition.to(button2, {alpha = 1, y = centerY + screenHeight\*.25}) elseif target == button2 then transition.cancel(rect) transition.to(button3, {alpha = 1, y = centerY + screenHeight\*.25}) button3.pressed = nil elseif target == button3 then goTrans() transition.to(button2, {alpha = 1, y = centerY + screenHeight\*.25}) button2.pressed = nil end end return true end button1 = widget.newButton({ label = "start transition", shape = "roundedRect", fontSize = screenWidth\*.08, width = screenWidth \* .75, height = screenHeight \* .1, onRelease = buttonPress }) button1.x, button1.y = centerX, centerY + screenHeight\*.25 button2 = widget.newButton({ label = "cancel transition", shape = "roundedRect", fontSize = screenWidth\*.08, width = screenWidth \* .75, height = screenHeight \* .1, onRelease = buttonPress }) button2.x, button2.y = centerX, screenBottom button2.alpha = 0 button3 = widget.newButton({ label = "re-start transition", shape = "roundedRect", fontSize = screenWidth\*.08, width = screenWidth \* .75, height = screenHeight \* .1, onRelease = buttonPress }) button3.x, button3.y = centerX, screenBottom button3.alpha = 0Although not mentioned in the maintenance log, Case 34162 is fixed in build 2376. (unless 34182 in the log was a typo).
I still have some further testing to do to see if all is well, but so far everything seems OK.
FYI.
I rolled back the workarounds I had in place for the transition API issues, and they all seem to be fixed with build 2376.
Even the last one I reported above without an official bug report, however it looked like it was related to bug 34276 which was reported by @schroederapps, and was reported as fixed in build 2376 as well.
Thanks.
I’m a happy camper again.