Timer still iterate even when it crash.

[morethanamotion]

Hi. When you hold down the minimize button or the close “x” button in the solar2D simulator for Windows, it is like crashing the application intentionally: transitions are pausing, but the timer.performWithDelay are still iterating its function🙂 I also see this in Samsung Galaxy J5, the app accidentally and unexpectedly crashes, and the timer.performWithDelay still iterate.

Try to run this code and then hold down the minimize or close button for a while and then release it,

	local function Berserk ()
		local bullet = display.newRect(display.contentCenterX, display.contentCenterY, 40, 20)
		bullet.rotation = math.random(0, 360)
		local rotationInRadians = bullet.rotation*math.pi/180
		local travelDist = display.screenOriginY
		local xDist = math.cos(rotationInRadians)*travelDist
		local yDist = math.sin(rotationInRadians)*travelDist
		local xDestination, yDestination = bullet.x + xDist, bullet.y + yDist
		transition.to(bullet, {x = xDestination, y = yDestination, time = 200, onComplete = function() display.remove(bullet) end})
	end

	timer.performWithDelay(250, Berserk, 0)

How to predict this so that I can cancel the timer… and more. Please help me. Thank you very much.

[XeduR]

I don’t think what you are describing is exactly what’s happening here.

Also, the application isn’t crashing. If it were, you’d get a runtime error and the problem would be elsewhere.

---

Both the transitions and the timers are time-based and you can see that the transitions don’t really pause either (in the way you might expect). If you run this code, you can see that when you release either of the two buttons, that the rect appears much further along than it was.

local rect = display.newRect( display.screenOriginX, display.contentCenterY, 40, 20 )
transition.to( rect, { time=5000, x=rect.x+display.actualContentWidth })

It seems that the simulator suspends when you begin holding down either of those two keys, and for some reason, when you let go of those keys, the simulator simply fires as many “missed frames” as it would have if it hadn’t been suspended in the first place.

You can see this by modifying your code a bit:

local iteration = 0

local function Berserk ()
    local bullet = display.newRect(display.contentCenterX, display.contentCenterY, 40, 20)
    bullet.rotation = math.random(0, 360)
    local rotationInRadians = bullet.rotation*math.pi/180
    local travelDist = 100
    local xDist = math.cos(rotationInRadians)*travelDist
    local yDist = math.sin(rotationInRadians)*travelDist
    local xDestination, yDestination = bullet.x + xDist, bullet.y + yDist
    transition.to(bullet, {x = xDestination, y = yDestination, time = 200, onComplete = function() display.remove(bullet) end})
    iteration = iteration+1
    print(iteration)
end

timer.performWithDelay(250, Berserk, 0)

You can see that the timer isn’t firing either when you “suspend” the app, but it’ll fire rapidly once you let go. For actual devices, you should watch for suspend system events. For the simulator, I’m not sure if you need to worry about it.

Just for reference, I’ve seen similar behaviour on HTML5 builds as well when the app is “half suspended.”

[morethanamotion]

Thank you very much, XeduR. I’m very sory, maybe I meant is the application is laging or in lag. But, is there a way to predict this so that I can cancel or pause the timer .etc?