Timer.CancelCallLater KeyNotFoundException

I sometimes get a KeyNotFoundException on Timer.CancelCallLater.
In previous versions there was a similar problem with an IteratorException on Timer.CancelCallLater.
Unfortunately I’m not able to reproduce the issue.
Do you have any idea what is causing the problem?
The exception doesn’t contain any errornumber, message or reason.

You can try to catch/ignore the exception or ask xojo tough a Fb request to ignore the exceptions e.g. if there is nothing to cancel they could just ignore the call to the CancelCallLater (which i’d prefer).

#pragma BeakOnExceptions False
Timer.CancelCallLater, AddressOf distStatus
Catch e As KeyNotFoundException
// Just ignore it.
Catch e As IteratorException 
// Just ignore it.
End Try
#pragma BeakOnExceptions Default

That’s probably internally on the xojo side.

You may be trying to cancel something that has already been cancelled.

1 Like

Normally I can call it as often as I want.
This doesn’t throw any exception:

Timer.CancelCallLater AddressOf test
Timer.CancelCallLater AddressOf test
Timer.CancelCallLater AddressOf test

Maybe a

Timer.CancelCallLater AddressOf test

Is internally some kind of lazy call and firing many, one after another, does not affect it. Try to create some timer that will fire in one minute, and try to cancel it twice in 2 different events (maybe another timer ticking at 3 seconds intervals, lazy calls should respond to each one).

Watch if the behavior confirms.

What is interesting here is that such behavior, if confirmed, is not documented.

On windows I could not reproduce.

I also would get “dictionary mutated while iterating” exceptions using Timer.CallLater. Inconsistently, of course. So I gave up and wrote my own.

My personal rule with Timer.CallLater is that I only use it to move things to the next event loop (time of 0ms). Any further and I use my own timer / class.

If someone knows that 0ms is skipped and handled instantly in the same stack please let me know immediately.