Xojo.Core.Timer.CancelCall

Looking at the documentation for Xojo.Core.Timer.CallLater and Xojo.Core.Timer.CancelCall makes me wonder about how CancelCall works.

As some may know I have been using a timer subclass that does the job of CalLater for years…

But I did not create a CancelCall equivalent because I did not need it. Now I am thinking about how I might have done it, I don’t see how i could since the whole point was for the end user not to have to keep a reference to the timer…

By the docs, to use CancelCall you pass in a delegate to the same method that you passed in when you started the timer with CallLater… It seems CallLater has to store a reference to the timer and the delegate with it under the hood…

But if the specific timer to kill using CancelCall is found by searching for the delegate, what happens if you have several CallLater timers going using the same method, perhaps with different periods and maybe different parameters (say you are passing in instances of different controls to operate on)?

Is that supported? If so I wonder how.

  • Karen

Anybody working with CallLater and CancelCall?

If so, can you use CancelCall if you have multiple CallLater timers running to which you passed the same method?

I don’t see how it could pick a specific one…

Thanks,

  • Karen

It’s looking at the Delegate so I think it will cancel anything that’s going to that method. Personally, I wouldn’t do multiple CallLater’s with different periods to the same delegate (and wouldn’t recommend it either).

I think it’s meant for ‘simple’ one-shot timers that many of us use. If you want something fancier I’d stick with what you already have.

Of course, some simple testing would tell us for sure.

[quote=155937:@Bob Keeney]It’s looking at the Delegate so I think it will cancel anything that’s going to that method.
[/quote]

I figured it would either cancel all or maybe the first one it might find or the first one instantiated (depending on how implemented under the hood). I could not see how it could do anything else… That was the point of my post.

I could see doing that for different control instances, and i’m sure someone will do it sometimes… So what the behavior is/limitations are should be clearly documented to prevent coding bugs because of mistaken expectations. I guess I should file a documentation bug report on that.

That does not have a away to CancelCall… I was wondering if I had missed something, and there was a way I could add that, as i did not see one.

I may create a version of my more flexible class for the new framework too as it would be a way to get familiar with it

  • karen