I just want to give kudos to the Xojo team for the most awesome API implementation of timers in the new framework. So happy they are available on the desktop now.
Being able to use the Xojo.Core.Timer.CallLater methods without having to set up a timer, add handlers, etc. is just brilliant. And having one of the shared methods allowing you to add a parameter for the method as well is just great. Really nice job guys.
I hadn’t see that. Nice!
Looking at the Overloaded version of the method
CallLater(afterMsec As Integer, method As Xojo.Core.Timer.CallWithArg, argument As Auto)I’m wondering if the argument shouldn’t be a param Array of autos for the argument instead, in case the method needs multiple arguments?
Actually you could do it with the old framework too with a subclass.
Some who need to stay on old version might find this handy:
http://katkosoft.xojonews.com/Persistent%20Timer/PersistentTimer.html
.
Unnecessary since the Auto can point to an array.
Now look at it this way: When you call the helper, you’d do this:
CallLater( x, MyMethod, param1, param2, param3 )But you’d have to set up MyMethod this way:
Sub MyMethod( arr() As Auto )Why? Because the only way CallLater could be written is this:
Sub CallLater (afterMsec As Integer, method As Xojo.Core.Timer.CallWithArg, ParamArray argument() As Auto)
method.Invoke argument
End SubMight as well stick with a single Auto.
What would actually be nice would be an arbitrary number of parameters. Then nearly any method could be used with these timer methods or without them.
Anyhow, it’s very slick…
[quote=182017:@Jon Ogden]What would actually be nice would be an arbitrary number of parameters. Then nearly any method could be used with these timer methods or without them.
Anyhow, it’s very slick…[/quote]
That’s essentially what I was asking about.
You can pass along a class of your own creation, so you can create an arbitrary number of parameters that way. Or pass a Dictionary or an array of Auto.
I try to use ‘CallLater’ and it works with one argument but when I code like below, I got an error.
“There is more than one item with this name and it’s not clear to which this refers.”
Can you let me know what is wrong?
Xojo.Core.Timer.CallLater(5000, AddressOf MyMethod, arg1,arg2,arg3)
# MyMethod
getargs() as AutoIt takes only one Auto but you can encapsulate whatever you want in it.
Untested but something like:
Dim Parms(), Parameters As Auto
Parms.Append(arg0)
Parms.Append(arg1)
Parms.Append(arg2)
Parameters = Parms()
Xojo.Core.Timer.CallLater(5000, AddressOf MyMethod, Parameters)
And catch Parameters on the other end and unpack them:
Dim Parms() As Auto = Parameters
Dim arg0 As String = Parms(0)
Dim arg1 As Integer = Parms(1)
Dim arg2 As Text = Parms(2)
Ah. Only one Auto.
Great. It works.
Thank you so much!
One thing to watch out for, is the object who’s method you’re calling going out of scope. In my limited testing, I’ve found that even with WeakAddressOf this can cause an application crash on El Capitan.
I worked around it by creating an encapsulating method which places a weakref on an array stack, then in the method it processes the first object (if it can resolve it) and then pops it off the stack.
Please file bugs for things like this.
Hmm now you mentioned that, I guess that’s the reason why I constantly ran into xojo.Core.IteratorException’s on xojo.Core.Timer.CancelCalls.
Because of those, I’m using Karen’s PersistentTimer. I had make a few tweaks (If .Haskey then .Remove) but it’s running super stable.
With things like this (where the errors happen at random and you don’t know the underlying reason) it is extremely hard to come up with an example or stripped down version of a larger project.
And when you do decide to file a bug report and explain it the best way possible, it is shot down because of the missing example.
Not very motivating.
Nice to know someone is using it! 
Okay, I’ll try to throw together a sample project. I didn’t actually consider it a bug as the object (window in my case) was released before the timer could fire.