David Kimmer wrote
> I have been using Director & Lingo since v4.0 and have recently been getting
> much more into the middleweight side of lingo with behaviours etc. However,
> the documentation on parent scripts does just not make much sense to me -
> maybe its because I am a designer as opposed to a full on programmer, but
> can anyone give me some pointers to their advantage in relation to a
> behaviour and how they work in conjunction with them - I'm really confused
> and want to further my lingo skills, but know that I will not get there
> unless I bridge this gap. Examples, Technotes anything welcome.
Hi David,
In most ways, parent scripts are just like behaviours. They both basically
create 'objects' with methods (handlers) and properties (variables). In the
old days of Director 3 & 4, parent scripts were called 'factories' (things
to make objects with).
To access the methods or properties of an object from outside an object, you
need to address the object, same as behaviours (eg. call(#AHandler,
Objectorbehaviour)). This can be contrasted to movieScript handlers and
global variables which can be accessed by simply referring to them.
The principal advantage of parent scripts is the same advantage of using
behaviours - that they support of the OOP programmer's mantra of
"abstraction, polymorphism, inheritance, encapsulation and reuse."
Basically, the philosophy underpinning this approach is that the best way to
solve complex problems is to break the problem down to (or build the answer
up from) a series of smaller, relatively simpler interacting objects.
Parent script objects are the same as behaviour objects. Once they have been
created, you can think of them as 'black boxes' -- you send them messages
and they respond with messages, and other objects shouldn't need to know how
they've been implemented.
Typically, behaviours contain all the handlers specific to the sprite
they're attached to: Button Behaviours handle mouse events, Alien Space ship
behaviours make the alien space ship fly around and blow up and so on.
Similarly, parent scripts contain all the handlers specific to the object.
The main difference is that behaviours reside in a sprite's
scriptInstanceList. This means that you can send the behaviour messages via
the sprite, and director automatically sends certain messages to behaviours
(Such as mouseDown, exitframe etc). Parent script objects need to have their
address explicitly set. If there isn't a reference to a parent script object
somewhere, then it dies (like when a sprite containing a behaviour ends,
unless there is something else referring to the behaviour, then the
behaviour dies).
You can store a reference to a parent script object (as well as behaviours)
in a global variable, or property of another object. For example
on startMovie
gObject = script ("Sound Manager").new()
end
--- "Sound Manager" parent script
on new me
return me
end
When an object is created from this script, director sends a reference to
the object as the first parameter. This is the 'me' parameter. When you
return the "me" parameter (with the "return me" line), you can store that
reference in a variable so you have an address of the object to send
messages to. So to send messages to the newly created object, you would do
this
gObject.mSomeHandler()
or
call(#mSomeHandler, gObject)
In practice, I tend to go through these steps when creating objects (same
process as creating behaviours)
1. What messages should the object receive
2. What messages should the object send
3. What kind of data should to object own
In big projects, this can be really helpful -- you can create a big
complicated system without having to remember the details of how each
component is actually implemented.
For example, I used to use a "SoundManager" object in most of my projects.
This object would
1. Respond to request to play a specified cast member
2. Tell any interested objects when the sound finished playing
3. Keep track of what sound channels are being used, what are free.
Other objects or behaviours could interact with this object simply by
sending it messages. The other objects don't need to know what is actually
going on inside the object. Over the years, this object (actually its a
series of related objects) has been refined and reworked. Its principal
methods haven't changed though. I could replace the script from an old
project with a new version of the script and the old project would still
work (in theory) because I haven't changed any of the handlers that other
objects call.
Luke
__________________________________________________________________________
Mecca Medialight Pty Ltd
Mecca Medialight: Medialight Sound Studio:
111 Moor Street 1 Bakehouse Lane
Fitzroy, Vic. 3065 North Fitzroy, Vic. 3068
Tel +613 9416 2033 Tel +613 9416 2033
Fax +613 9416 2055 Fax +613 9416 2055
http://www.medialight.com.au
__________________________________________________________________________
[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!]
