Timer.CancelCall(AddressOf partyTime) // Do we care here?
Timer.CallLater(2000, AddressOf partyTime)
Does it matter if I’m cancelling a call even if there was never one made?
The purpose of the above code is to allow me to call partyTime repeatedly and every time it’s called, we wait another 2 seconds. Then 2 seconds after things calm down its partyTime! Of course, it could be called just once.
maybe somebody from the Xojo team knows this ?
Or you could try it…
There’s only 2 designs possible, raising an exception because it wasn’t found, or being ignored, because it wasn’t found.
So try it. If it does not raise an exception it was ignored and it is safe. If it raises, catch it and ignore yourself.
On windows, no exception (32/64 bit both) no nothing. That’s great since exceptions are SLOW and these calls may be required to be fast (animations etc).
Not sure about macOS yet.
SHOULD follow the same guidelines or would be an inconsistency.
Yes, it doesn’t raise an exception. It just seems to ignore the CancelCall. Hopefully without adverse affects…
It should be ok but the only thing I’d recommend is to wrap it all in a Try to check for IteratorException which I’ve seen happen.
It would be nice if this was documented (<https://xojo.com/issue/57720>) as you’d only ever know about checking for it when your program randomly broke.
Are you telling us that you saw a CancelCall raising an IteratorException or I didn’t understand it?
I can confirm this.
We also had this issue that sometimes a CancelCall raises an IteratorException.
Is wrapping it in a Try any more efficient performance wise than catching the exception at the bottom in a “Exception err as…”?
Yes
I’ve not done any performance testing on Try’s to offer an opinion either way, but if its just in a UI update system somewhere I wouldn’t worry about the performance hit.
I guess error “0” is just a warning about the use of the underlying dictionary. But kind of looks like a bug. How could you mutate the underlying dictionary while calling a CancelCall? But now we know we MUST use try catch and ignore such “warning”. But I’m highly curious on why this happens because it may be related to more bugs, or it’s ok, and the warning message is just plain wrong and could be something like “Handler pointer not found”.
Its an error not a warning, the 0 is there because no error number is returned with the error. The error message is perfectly valid for what I suspect is happening which is the loop that clears the dictionary down yields allowing modification of the dictionary while its being cleared.
I can’t see it happening with such fragment of code you have shown, there is more code?
Yes
That happens if you do something like
#Pragma BackgroundTasks False
Timer.CancelCall(AddressOf myHandler)
#Pragma BackgroundTasks True
?
^ Edited to add the interrogation above
Do you see that code in my screenshot?
Yes, I want to find the bug and propose a fix for Xojo
Yes? I looked at the screenshot again, just to double check. You see a #Pragma in my screenshot?
No. I don’t, That’s why I asked you to try it.