Xojo.Core.Timer.CancelCall can cause Xojo.Core._DictionaryIterator.MoveNext exception

Timer.CallLater is terribly handy!

To prevent repeated calls to the same method while we’re waiting, I’ll often cancel the first call before starting another like this

Xojo.Core.Timer.CancelCall(AddressOf MyMethod) // This doesn't check if there is an existing call to cancel. It just tries blindly Xojo.Core.Timer.CallLater(1000, AddressOf MyMethod)

However this on odd occasions under Windows results in an exception:

Xojo.Core._DictionaryIterator.MoveNext

Am I doing something wrong or should I just catch the exception and move on?

What version of xojo are you using?

Sorry, Xojo 2019r1.1

I’m not able to reproduce this but there’s unfixed talk of it happening in feedback. Are you able to reproduce this in a small demo project as the order things happen might be key to reproducing it for it to get looked at?

Aside from that I’d say catch the problem as it would seem its an issue in the internals of the framework when the timer dictionary is being modified during an iteration which shouldn’t be able to happen.

While trying to reproduce this I did find a reproduction step on another issue in windows, silver lining and all that :wink:

I tried a tiny project and wasn’t able to reproduce it, alas. It’s a pretty rare bug.

Thanks for trying! Glad you got a silver lining! I’ll just catch the error and move on.

I’ve run into this plenty. There is absolutely a bug in the framework, but I’ve never found a way to reproduce it either. I just wrote my own CallLater module and moved on.

I don’t think the issue requires the use of CancelCall either. I think it is more likely related to scheduling a new callback from within code executed by a callback, but again, wasn’t able to reproduce it.

I wonder if this might be related to the issue of Xojo.Core.Timer.Calllater calls being processed in FILO order on Windows. Don’t know if this has been fixed because of the Xojo framework deprecation soon after ticket creation.

I’m finding my app is still crashing from this even though I’m explicitly catching exceptions. For example, this would be a description of the exception:

Dictationary was mutated while iterating over it

I’m not dealing with dictionaries in that call so I assume this is an internal dictionary related to callLater

And a stack trace

Xojo.Core._CallLaterTimer.Event_Action%%o<Xojo.Core._CallLaterTimer> Delegate.Invoke%% Application._CallFunctionWithExceptionHandling%%o<Application>p REALbasic._RuntimeRun _Main main

I have a API 1 replacement for call later that i wrote a few years ago here:
http://katkosoft.com/Persistent%20Timer/PersistentTimer.html

[quote=489686:@Stephen Dodd]I’m finding my app is still crashing from this even though I’m explicitly catching exceptions. For example, this would be a description of the exception:

Dictationary was mutated while iterating over it

I’m not dealing with dictionaries in that call so I assume this is an internal dictionary related to callLater

And a stack trace

Xojo.Core._CallLaterTimer.Event_Action%%o<Xojo.Core._CallLaterTimer> Delegate.Invoke%% Application._CallFunctionWithExceptionHandling%%o<Application>p REALbasic._RuntimeRun _Main main [/quote]

That sounds like your call to:

Xojo.Core.Timer.CancelCall(AddressOf MyMethod) 

is being done while xojo is iterating over the items in a dictionary (probaly holding the addresses of the delegate functions).
Your code modifies something, it may be xojo need to add a

#Pragma BackgroundTasks False 

In their iterating code.

Do you have a bug report for this?