Thank to Roy Pardy and Andreas Gaunitz for their suggestions on
how to mute a timer. Here's some further notes about this.
Roy Pardy wrote:
>I turn off but retain a timer object just by setting its period to 0:
>myTimeoutObject.period = 0
For want of a .enabled prop, imo this is the best workaround to turn off
a timeout object and the least disturbing for it.
Andreas Gaunitz wrote:
>1) You can 'mute' a timer by using:
>
>myTimeoutObject.timeOutHandler = ""
>
>and unmute it by setting the timeOutHandler to whatever handler you need.
That's OK. But how much time does it takes to a p-code executable
to un/re-install the handler into the target all the times?
The same holds about destroying and rebuilding the timer object.
I never attempted to measure it as I assume that a boolean is the
best way to mute a timer, expecially if this boolean is a property
of the timer object itself.
>>2) Synchronizing the release of timeout events with the
>> exitFrame events.
>
>2) I'm not sure that I fully understand why you want to do this.
>
>a) Either you want to keep the timer going, but in muted mode, and
>then make it unmuted when exitFrame occurs, in which case you do like
>in (1).
Yes. This would allow to get a burst of events near each other
in time, and the first of them would be released just when the
exitFrame event is. Like this:
|<-------1/FPS------->| | exitFrame
|||||||||| |||||||||| |||||||||| timeout: 1/(n * FPS)
The bursts of events represented above are assumed to be triggered
by the exitFrame events. At the 10th event of each burst the timer
gets muted by some appropriate logical device - e.g. a counter or so,
or by another timer.
The situation depicted above could be interpreted as the attempt
to replace repeat loops with timeout events - loops of 10 steps,
in the example.
Working e.g. with multiple collisions I found that the FPS decreases
dramatically when the program is busy in long repeat loops.
(Some people use to move part of the code to the idle event handler).
A fact is that FPS seems decreasing a lot cause more of the
loop itself than for the amount of code contained in a loop cycle.
Some tries with timers confirmed it (from 20 FPS to 60). But the
problem is just having these timers in full control, otherwise either
the code turns into a rigmarole or/and the working is irregular
since some operation are initiated prior than some others have been
accomplished.
Notice also that if a timer could be forced to release its first
event upon the completion of the execution of the code where its
.enabled prop is set to TRUE, it could be triggered by the
events of another timer, and so on.
>b) Or you want the timer to reset on exitFrame. In this case you
>would not get a timer - you'd get something that stutters every
>exitFrame.
I'm not sure of having well understood this second case you posed
as a distinction.
I seem a timer can't be never reset, whether you was meaning that
the internal time count is resettable to zero. Just from its birth a
timer shows an initial time value that is related with the system time.
But I guess you referred to a reset timer as to a forgotten one
and not to a particular value of its internal time.
If so, I'd agree with you. But, from the point of view of an
object that is getting events from it, I can't see the difference:
the object would hear as stuttering a timer that periodically resets.
Though also a periodically muted timer stutters, doesn't it?
In the end, I find the timeout a very important feature, not only
because it's accessible as an object but also because it releases
events. Well, if you compare the Lingo timeout object with the
Visual Basic Timer Control, you may see a noticeable similarity
between them. The timeout object from MM is provided with even more
features, but unfortunately it laks _just_ a .enabled prop.
Regards,
Franco
IFC Programming Consultant
http://www.chnexus.com/main.htm
Private mailto:[EMAIL PROTECTED]
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
