Thanks for the definitions you posted some day ago. They are
so neat that it was worth while trying to show how they well
fit to a hardware device that generates e.g. a squared waveform.
Thia comparison helped to reformulate my request to Macromedia
in order to get some timeout object's control enhancement.
I hope having well interpreted your analysis.
Andreas Gaunitz wrote:
>By 'resetting' I meant something like (Alpha):
>'Make the timeOutObject output its Handler Call Now and make it count
>from 0 up to its timeoutObject.period (as if it was just created)'.
Referring to a device that generates a square wave, say a counter,
the low-to-high level transitions of its output signal could be
thought as corresponding to the target object's handler calls of a
Lingo timeout object. The counter transitions are distant T. in time.
Likewise, the Lingo timer outputs calls every .period milliseconds.
If I am not wrong, a counter resets when its internal units (e.g.
flip-flop) are forced by some external/internal signal, to resume
their initial status. So the counter restarts to count from 0 and
contemporary releases the first pulse ("output its Handler Call
Now") of a new sequence.
When a counter gets reset pulses, I think you say it "stutters"
in so far as it keeps repeating the sequence from the start, as
people do with words, or, equivalently, it loses its pace.
Since an hardware device can't be 'deleted' as a software object,
it is provided by some reset functionality: for some applications,
like the software ones of mine, it could be useful having it reset
in concomitance with other events or conditions.
The timeout object doesn't have a "reset pin" to date. So it must
be deleted and rebuilded if we want it reset. This would lead to
the code you suggested in your very first replay:
----
on exitFrame(me) -- <--- Resetting event
timeout("myInterval").forget()
timeout("myInterval").new(50, #tryNextStep, me)
end
on tryNextStep(me)
-- do stuff every exitFrame + every time a timeOut occurs
end
----
This could suggest to Macromedia to add a method reset() to the
timeout object, hopefully faster than the object's destruction,
so to have:
on exitFrame(me)
timeout("myInterval").reset()
end
And this would be the most desirable enhancement.
>as opposed to 'unmuting' which would just (Beta):
>'Let the timeOutObject output its Handler Call at the next occurance
>of a timeOut, which might be anything from 0 ms to
>timeOutObject.period'.
According to the comparison I set above, in this case the counter
output waveform would be sent to a, say, AND gate. The counter never
would reset nor lose its pace. Instead, its signal is prevented from
exiting the unit cause of the enable/disable action of the gate.
This type of "gated" behavior is quite easy to setup in Lingo by an
user defined flag. For example, if 'me' is the instance of an object
that receives the events of a timer by its own method tryNextStep
(the target) and 'enabled' is also a prop of 'me', we could set:
on tryNextStep(me)
if not enabled then exit
-- do stuff every time a timeOut occurs
end
Though, imho, inserting the flag into the target downgrades the
quality of the coding, particularly when a class allocates its
own timer:
--Parent Script "TimedObject"
property theTimerEnabled
on new(me)
theTimerEnabled = FALSE
timeout("theTimer').new(20, #tryNextStep, me)
return me
end
on tryNextStep(me)
if not theTimerEnabled then exit
-- do stuff every time a timeOut occurs
end
If we set hTO = (script "TimedObject").new(), then we should
issue hTO.theTimerEnabled = TRUE/FALSE. This would mean to ask
hTO to enable/disable "its property of accepting/rejecting the
timer calls".
Instead, if we would able to set a .enabled prop:
--Parent Script "TimedObject"
property theTimer
on new(me)
theTimer = timeout("theTimer').new(20, #tryNextStep, me)
theTimer.enabled = FALSE
return me
end
on tryNextStep(me)
-- do stuff every time a timeOut occurs
end
we would issue hTO.theTimer.enabled = TRUE/FALSE to request
to hTO to enable/disable "its timer".
And this would seem to me more in accordance with the lexis by
which a property of an object set as a property of another object
is generally accessed.
A last notation, the above arrangement:
theTimer = timeout("theTimer').new(20, #tryNextStep, me)
theTimer.enabled = FALSE
could not work properly because, if the timer outputs its handler
call once created, setting its .enabled to FALSE just after new()
might not prevent it to perform at least the first call.
So it would seem reasonable that the initial value of .enabled needs
to be passed to the constructor through a further argument.
If so, I'd suppose that Macromedia won't never add such prop to the
timeout object for sake of backward compatibility.
BTW, thanks for the possibility of these reflections.
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!]
