this seems to me to be quite powerful, although i can't say exactly why
at the moment. and yes, it's prolly not so programmatically kosher, but
it's pretty cool.
"Mark R. Jonkman" wrote:
>
> Hi Bhakti
>
> I just did a little test, simple movie (kinda annoying to work with) but it
> basically worked likes this:
>
> frame 2 framescript
>
> on exitFrame
> it = new(Script "Test")
> end exitFrame
>
> frame 5 framescript
>
> on exitFrame
> go the frame
> end exitFrame
>
> please note that in the first exitframe handler on frame 2, it is a local
> variable.
>
> Parent Script named "Test"
>
> property pSpecialTimer
> property pCount
>
> on new me
>
> pSpecialTimer = timeOut("theName").new(0, #someNonExistantHandler, me)
> pSpecialTimer.persistent = true
> return me
> end new
>
> on exitFrame me
> pCount = pCount + 1
> if pCount = 300 then
> put "Hello"
> pCount = 0
> end if
> end exitFrame
>
> on remove me
> if objectP(pSpecialTimer) then
> pSpecialTimer.forget()
> end if
> end remove
>
> run the movie
>
> -- every so often you will see the line:
>
> --"Hello"
>
> there should be just enough time to do type a few messages into the message
> window to see what is actually going on.
>
> put the timeOutList
> put the timeOutList
> -- [timeOut("theName")]
>
> put the timeOutList[1].target
> -- <offspring "test" 2 1d7714>
>
> of course the odd time the word "Hello" will appear so you have to work
> reasonably fast.
>
> if you type:
>
> the timeOutList[1].target.remove()
>
> then "Hello" no longer appears
>
> put the timeOutList
> --[]
>
> So it appears that you can safely store a reference to an object into the
> timeoutList stored as the target of the timeOut object
>
> Of course I could well have just destroyed the object by killing the
> reference to the timeOut object itself:
>
> the timeOutList[1].forget()
>
> or
>
> timeOut("theName").forget()
>
> Remember, a reference to the timeOut object itself is stored in the property
> of the original object and thus I didn't need to type the name of the
> timeOut object as you suggested, rather just call forget on the reference to
> the timeOut object, ie:
> pSpecialTimer.forget()
>
> I guess it would be more "proper" to not crossreference the two objects, I
> haven't tested it but you should in theory be able to not store the
> reference to the timeOut object in the actual object. I hadn't actually
> thought of the fact that the timeout object reference to the the "test"
> object would hold that "test" object in memory, but it certainly beats
> having to store it in a global object, but it makes for one nasty mess of
> trying to reference it... but that's another story. If it is simply running
> along doing a repetitive function based on start, stop or frame events then
> it might be a fairly good idea. Of course you can always get the reference
> back by retrieving the target of the timeOut object provided that its name
> is a "constant".
>
> Okay, I'll quit blabbering on.
>
> Sincerely
>
> Mark
>
> --------------------------------------------
> Mark R. Jonkman
> Mark R. Jonkman Consulting
> ADDRESS: 20 Windermere Crt., Guelph, ON, CANADA N1E 3L4
> PHONE: 519-837-8509
> EMAIL: [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!]
--
R. Bhakti Klein
Multimedia Programmer, Distributed Learning Workshop
http://www.dlworkshop.net/
··
Baritone, Wicki6
http://www.wicki6.com
···
"On Earth, you can only do little things;
but you can do them with a lot of Love."
-- Mother Theresa
[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!]
