Hello Christian, thanks a lot for bringing more clarifications.
Yes, you are right, calling the timeOut().new() in stepFrame() will soon end
up in a timeout porridge.
You proposed one more handler:
on destroy(me) timeout("timer1").forget() end
but I've tried to do without it, and it "somewhat" worked. (I don't know if
it's allowed though).
When the movie was running, in the message window I did this: put the timeOutList -- [timeOut("timer1")]
when I stopped the movie it looked like this: put the timeOutList -- []
that is, as you stated yourself, myObject = VOID did the clean up of the
object, but, as I've figured out, of the timeout object as well. Don't know
if I'm wrong though.
So the ending script (and now simplified a bit) looks like:
-- Frame behavior on exitFrame(me) go(the frame) end
-- Movie script on startMovie() myObject = script("car").new("bmw", 220) end
on stopMovie() myObject = VOID end
-- Parent script property name property velocity
on new(me, tName, tVelocity) name = tName velocity = tVelocity timeOut().new("timer1", 2000, #showInfo, me) return(me) end
on showInfo(me) put ("My name is") && name put ("My velocity is") && velocity end
Hi Peter,
I think what you're seeing is Director's garbage collection at work. However, you have to be careful relying on this. Since you have created a pointer to myObject in your timeOut object, myObject may never be garbage collected, even though you set it to void.
In addition, you don't seem to be declaring myObject as a global variable,
so it is effectively a local variable in your startMovie handler, and
therefore setting it to void in stopMovie will have no effect.
You can do a "put myObject" in the message window to get more info on the
innards of the object that you have instantiated. So in your example, the
message window returns:
-- <offspring "car" 3 4ed0d20>
Without the timout object:
-- <offspring "car" 2 4ee1cb0>
As you can see, the first has a 3 where the second has a 2, and they both
have different addresses in RAM (the last long number). The 3 and the 2
denote the number of references *to the object* and garbage collection is
only supposed to be automatic on objects which have no pointers to them
held elsewhere.
So what is happening is that your timeOut object has a pointer to myObject
(which it needs to send the event to that object) but when the object is
destroyed, there is still the pointer to it lurking in the timeOut object.
myObject should therefore never get garbage collected and will persist as
a lonely orphan in RAM until Director quits.
OOP is not an exact science - and what I'm suggesting is not absolutely
necessary. But I think it is good practice, as I mentioned before, to
explicitly destroy that which you have created when you no longer require
it. I apply this technique to all objects, and have found that it makes
my code cleaner and less prone to strange behaviour.
Bests,
Chris
[To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/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!]
