Forum TI-Planet.org

There have been multiple cases where i closed a file on the Ti-Nspire CX and after i open it again it is frozen.
It seems like the timer.start function wont work after reopening a file. This problem cant be replicated in the emulator on PC.
Is this problem already known? And if it is, is there a solution?
Can anyone help me with this?

Edit: It is known that the timer stops when the document containing the script is closed. That includes turning off the calculator.
I have the problem that the timer.start function doesn't seem to work when turning the calc of and then on again.
After turning the calc on you see the document for a split second before you return to the home-menu.
If you open the document right now it's in the same state as before you turned the calc of.
Except that the timer was stopped and the timer.start function won't work anymore.

Is there some kind of workaround? Or do i just have to life with this?

Where do you put the timer.start in your code?
There are some event functions that get launched on start, so it may need to be there. A good place where everything will be initialized (might not be needed in your case, I don't know) would be on.resize

Could you post your code?

I tried to put it in on.activate. i'll send my code later because i'm on my mobile rn.

So i just did some testing.
Here is the code:

Code: Tout sélectionner

platform.apilevel = "2.0"

local pww, pwh = 318, 212;

local startTime = timer.getMilliSecCounter();
local curTime = 0;

local tstart = timer.start;
function timer.start(ms)
   if not timer.isRunning then
      tstart(ms);
   end
   timer.isRunning = true;
end
local tstop = timer.stop;
function timer.stop()
   timer.isRunning = false;
   tstop();
end

local functionCalls = {};

function on.resize(w, h)
    pww, pwh = w, h;
end

function on.timer()
    curTime = timer.getMilliSecCounter() - startTime;
    platform.window:invalidate();
end

function on.paint(gc)
    gc:setColorRGB(0);
    gc:setFont("sansserif","r",12);
    local y = 20;
    for i=1, #functionCalls do
        gc:drawString(functionCalls[i], 10, y);
        y = y+15;
    end
    gc:setFont("sansserif","b",24);
    gc:drawString(curTime, (pww - gc:getStringWidth(curTime))/2, pwh/2, "middle");
end

function on.construction()
    table.insert(functionCalls, "construction");
    timer.start(0.01);
end

function on.deactivate()
    table.insert(functionCalls, "deactivate");
end

function on.activate()
    table.insert(functionCalls, "activate");
    timer.start(0.01);
end

function on.enterKey()
    table.insert(functionCalls, "enterKey");
    timer.start(0.01);
    platform.window:invalidate();
end


There was another strange occurence that i discovered during this.
In the emulator the eventcalls are like you would expect: first on.construction then on.activate.
But on my calc it was strange: the first two calls are the same. But then on.deactivate gets called followed by on.activate once more.

Now to the main subject of this thread:
The timer continues if i close the document by pressing the home button and the opening it again. Just like it should. But when i am in the document and turn the calc of with ctrl+home and turn it back on again i see the document for a split second before the home screen is shown. If i open the document now the timer is frozen and won't start no matter what i do. In case the events aren't called I added on.enterKey, which works even when the timer is frozen.The timer only starts working again after completely restarting the script.

My calc is a ti-nspire cx
OS is v4.5.1.12

It's been a long time since I experimented with the timer, but I recall some similar experiences, though mostly related to hidden crashes during serialisation (with on.save/on.restore).

Could you try some experiments without the apiLevel directive? It can cause the script to restart if the API level hasn't been set inside the TNS yet. Or, you could try to load the document, save it, close it, re-open it, and see if the behaviour is the same (force saving the document will store the API level details in the XML).

The behaviour with the multiple active/deactive stuff might be related to these script restarts, but regardless they have always odd