Bruce and Steve,
Sorry, and maybe my brain already has gone for its weekend. Yet, it
seems to me, that somehow you are contradicting each other, or at least
dealing with two different perspectives of the matter.
According to Steve's message - did I read it correctly - any timer that
has timed out, will automatically "die", and does need no further
stopping or destruction. That is what I thought, hence my sample code. I
still wanted to make sure I got things the optimal way, why I posted my
question to the list - also hoping that the answer may serve to help
others who would be wondering the same. The Developer's Reference was
not exactly clear on the matter, the way I found it.
Then, just after reading Steve's message - putting me all at rest - I
read your comment Bruce, as quoted below. If a timer has timed out, in
reality is dead, why would I need to check for any numbers or other
settings of that timer? If it has died, wouldn't it just return either 0
or Nothing anyway? So what would all that extra coding do for good,
other than forcing the app to perform a load of rather useless cycles.
Since the process is ongoing for each interval - in my example every 1.5
seconds - I would much prefer as few cycles be repeated on each go.
Otherwise, it might just end up slowing down the system over time. But
the way I read your comment Bruce, it seems that you are saying that
unless I perform these extra checking steps on the timer, it may still
be sitting there and taking up empty space or resources in memory? That
it somehow will leave its trash behind, and just start new processes on
top. That is not exactly what I read out of Steves's message as quoted
further down this message.
Again, sorry if I am misinterpretting either one of you. I just wanted
some clarification. I do understand that I would need to call the
StopTimer if the process had to end, but it is not going to end until
the app is closing down, and I have already a call for the StopTimer as
part of the closing procedure. So again Bruce, what exactly is it you
are trying to convey?
Thanks again,
Bruce Wrote:
The timer makes another number each time it is called, usually in
sequential order, but that number must be kept to destroy the timer
setting it was associated with. So always check for a number greater
than 0 and stop it if you are starting over again.
Bruce
On 2/20/2015 2:41 PM, Steve Clower wrote:
David,
What you have written below is correct given what you want to do. The
timer methods within the Window-Eyes Scripts object do not repeat, so
calling StartTimer again inside your timer proc is the correct way to
ensure it fires every 1.5 seconds.
You would use StopTimer if you wanted to cancel the next firing of your
timer proc.
HTH,
Steve
On 2/20/2015 12:25 AM, David via Scripting wrote:
I have the following frame code:
Dim TimerID: TimerID = StartTimer( 1500, "MyTimer")
Sub MyTimer()
' Do my stuff.
TimerID = StartTimer( 1500, "MyTimer")
End Sub 'MyTimer.
This code is meant to perform a certain small test, every 1.5 second.
After performing the action, it should restart the timer, and 1.5
seconds later, do the same test over again. The procedure is meant to
run permanently, long as the app is running.
What I wonder, is if I need to use the StopTimer instruction, before I
call the StartTimer for next interval. If I do not use the StopTimer,
will it automatically reset the StartTimer when I call it next time?
Or, is the StopTimer necessary to clear up anything in this process?
Hope my question made sense. Thanks for your input.
_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/archive%40mail-archive.com.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
