Timeouts objects are a great feture of the new Director
generation. They look like fully self-contained objects
able to send events to any previously defined method in
another class or to a movie level handler.
I think it would be seemingly simple for Macromedia adding
a property "enabled" to its timeout object. Introducing
such prop imho would lead to a cleaner and faster code.
We'd get at least two advantages from this:
1) Simplifying the timeout object control
If you want to stop/resume the timeout events from being
received by e.g. the method mGetTimeOutEvent of an object
that uses the services of the timeout object, up to date you
have to initialize and mantain a Lingo boolean flag:
on mGetTimeOutEvent me
if not enabled then exit -- here enabled is a prop of me whose
......... -- book-keeping is made elsewhere
end
2) Synchronizing the release of timeout events with the
exitFrame events.
The timeout object events run asynchronously in respect
with all other Director events, e.g. the exitFrame events.
Look at the figure below, where exitFrame and timeout
events have been represented versus the time.
| | | | exitFrame events
<----- Te ---->
||||||||||||||||||||||||||||||||||||||||||| timeout events
To
Due to the asynchronous nature of the timeout events,
the train of the timeout events continuously shifts
in respect with the exitFrame events train.
(Electronically speacking, with a double trace oscilloscope,
if you keep stationary the trace of the exitFrame pulses
by triggering the ramp by them, you would see the lower trace
moving to left or right in respect with the upper)
If Te >> To you have _pretty_always_ the same number
of timeout events into an interval of time Te, just as
in the figure, or, to say better, a little percent error.
But if the inequality above does not hold, you get a
different number of timeout events into Te. For example
you get 3, 2, 3 etc. timeout events in this situation:
| | | | exitFrame events
<----- Te ---->
| | | | | | | | | timeout events
<-To->
3 2 3
Whether we were allowed to assume that, upon issuing
timeout("MyTimeOut").Enabled = TRUE into an exitFrame
handler, the first timeout event will be released just
at the end of execution of all the code attached to the
exitFrame handler itself (or, alternatively, after a
time To since the completion of its execution), we would
get a simple way of synchronizing the two trains of events.
I'd like to know what other Developers think of this,
and eventually which further features they wish to see
added to this really important new feature of Director.
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!]
