What causes a timer.performWithDelay function to stop triggering?

I have a function in a non-main lua file, say Foo:Bar(), where inside I use timer.performWithDelay to delay and iterate an inner function inside Bar() 15 times (or 20, doesn’t matter).

However, inside this inner function that I’m repeating, I am calling a function in main.lua.

If the main.lua function that I call is just a mere print (to console), nothing’s wrong.

I start doing something more with it, then the inner function scheduled to repeat stops repeating.

I’m almost certain that I’m not making any stupid syntax mistakes, or trying to reference nil variables, common causes of runtime problems that aren’t detected during the Corona Simulator launch.

Is that function in main.lua local or global?  How are you referencing it?

Can you post your code for your timer call?

Nevermind, I fixed it by doing away with the timer delay. I’m still not sure why it wasn’t working, and my code is a bit nonsensical to read, but my conclusion was that:

Scheduling the function to be performed with delay AND THEN adding some enterFrame listener elsewhere probably caused something to jam - like whatever the actual code is using to keep track of the inner function’s timer.performWithDelay function to become out of scope. 

Or, there was a mistake in my code, since I might’ve tried to call another function of the same .lua file while an inner function was supposed to be performed again - not sure.

Or in some cases I’ve found that requiring too many different things to be performed at a near-FPS speed to be too demanding. Its as if every 30-40 ms I have to perform a bunch of calculations, and I have to execute a whole bunch of code, which takes so long that some of the code eventually “misses” every few frames or so? 

If possible, it’d be helpful to know the inner workings of timer.performWithDelay, and how it might possibly interfere with enterFrame listeners. I think that was what I was trying to say.

timer.performWithDelay() and enterFrame listeners should not interfere with each other unless you are setting a timer inside an enterFrame listener and trying to set 30 or 60 of them per second (which would quickly overwhelm the system) or your timer is firing too quickly and spawning too many enterFrame listeners that could be trying to work on the same data at the same time 30 or 60 times per second.

local count = 0 local countText = display.newText(count, 0, 0, native.systemFontBold, 32) countText.x = display.contentCenterX countText.y = display.contentCenterY   local function doSomething()       count = count + 1       countText.text = count end   -- create a new enterFrame listener every 10th of a second indefinitely timer.performWithDelay(100, function() Runtime:addEventListener("enterFrame", doSomething) end, 0)

Now in my test of the above code, I’m well over 1,000,000 executions of doSomething() and it hasn’t crashed yet, but you can see how this could get abused in a hurry.

Is that function in main.lua local or global?  How are you referencing it?

Can you post your code for your timer call?

Nevermind, I fixed it by doing away with the timer delay. I’m still not sure why it wasn’t working, and my code is a bit nonsensical to read, but my conclusion was that:

Scheduling the function to be performed with delay AND THEN adding some enterFrame listener elsewhere probably caused something to jam - like whatever the actual code is using to keep track of the inner function’s timer.performWithDelay function to become out of scope. 

Or, there was a mistake in my code, since I might’ve tried to call another function of the same .lua file while an inner function was supposed to be performed again - not sure.

Or in some cases I’ve found that requiring too many different things to be performed at a near-FPS speed to be too demanding. Its as if every 30-40 ms I have to perform a bunch of calculations, and I have to execute a whole bunch of code, which takes so long that some of the code eventually “misses” every few frames or so? 

If possible, it’d be helpful to know the inner workings of timer.performWithDelay, and how it might possibly interfere with enterFrame listeners. I think that was what I was trying to say.

timer.performWithDelay() and enterFrame listeners should not interfere with each other unless you are setting a timer inside an enterFrame listener and trying to set 30 or 60 of them per second (which would quickly overwhelm the system) or your timer is firing too quickly and spawning too many enterFrame listeners that could be trying to work on the same data at the same time 30 or 60 times per second.

local count = 0 local countText = display.newText(count, 0, 0, native.systemFontBold, 32) countText.x = display.contentCenterX countText.y = display.contentCenterY   local function doSomething()       count = count + 1       countText.text = count end   -- create a new enterFrame listener every 10th of a second indefinitely timer.performWithDelay(100, function() Runtime:addEventListener("enterFrame", doSomething) end, 0)

Now in my test of the above code, I’m well over 1,000,000 executions of doSomething() and it hasn’t crashed yet, but you can see how this could get abused in a hurry.