At 22:01 +0800 05/10/2002, noelle cheng wrote:
>>What other messages do you mean? When a movie stops playing
>>(because of a quit or halt command), endSprite events on any
>>sprites >in the current frame will execute, after which a stopMovie
>>event is generated. If there is a stopMovie handler defined, that
>>will then run.
>
>Messages like MouseUp. Could they be used in this context?
I don't know what you're asking here. :( Are you referring to whether
mouseUp handlers can be written into behaviors?
>By the way, how do I define a stopMovie handler?
In the same way you define any othe regular movie script handler,
such as startMovie, or custom "global" scripts. You open a script
window and do something like this:
on stopMovie
ALERT "Quitting!"
END stopMovie
>On page 221, it is written:
>
>'However using a halt command in a projector is not a good idea,
>because with versions prior to 8.5, halt did not call the stopMovie
>handler. This is very important to know ,because you will often use
>stopMovie to save progress files, restore settings you have changed,
>and so on. '
>
>I thought there was a save as command to do this?
That affects the faules in authortime only. If you're using FileIO or
setPref to keep track of a user's score (as an example), you will
want to save that on your own using custom handlers you've written
for doing so.
>You also mentioned on page 220 that quit would not work in a
>Shockwave movie, so we shouldn't be using it?
Don't use it in Shockwave and expect it to work, no. It won't quit
the browser; it will simply stop movie playback.
>>That's why in that case it might make more sense to do a
>>two-behavior approach. The volume button behavior would be the
>>sending behavior; and to the QuickTime sprite you would attach
>>another behavior that receives. That way you'd be less likely to
>>get script errors.
>
>This is still not object oriented programming?
Yes, it is.
>Actually the purpose of OOP is to create objects and use them?
No, the purpose of OOP is to use objects' natural encapsulation
ability to protect your program from being more crash-prone, and to
(essentially) create mini-programs that, once oyu've put them all
together, generate a meta-program.
>But why do we need to create objects? There is no other way?
Properly written object code is very stable, very robust. Parts of it
can fail while the overall program continues to function. (Ideally
none of it fails of course -- part of the object design is about
error trapping and handling, and in fact a *lot* of the work an
object does is nothing but looking for and squashing errors.) There
are lots of non-PPO languages out there and you don't have to use OOP
design to make Director programs either, but it is definitely the
wave of the future.
What this is is abstraction. The more you abstract data from
interface, the harder it is to break things.
>What is the difference between a behavior and a parent script?
Parent scripts instantiate into variables, in more or less the same
way an Xtra operates; while behaviors are attached to sprites and
therefore Score dependent. (In general!)
>I notice something . You are using loops here? i.e. if ,else, end
>if. Actually it was already present in the previous script.
>These are conditionals, aren't they?
Yes, they test that a certain condition is true before deciding what
to do next.
>I need to learn to write this type too, isn't it? Normally you use
>this type of script to limit or restrict the conditions?
Not just that. You also write it as a form of error trapping, as I
did with the void tests. It doesn't hurt to confirm the integrity of
a variable before proceeding to work with it.
>> if sprite(me.spriteNum).member.type <> #quickTime then
>> exit
>> end if
>The surprising thing was that when I used this script, it didn't
>work, i.e. the volume remained constant. I was not able to make the
>volume louder or softer. Why is that?
I blew the syntax. The test for type should be #quickTimeMedia, not #quickTime:
if sprite(me.spriteNum).member.type <> #quickTimeMedia then
exit
end if
>What is the meaning of the <> sign?
Not equal to. So in the message window you could do this:
put 3 <> 2
-- 1
put 3 <> 3
-- 0
In the first case you are testing to see if 3 is not equal to 2;
that's true. In the second case you're seeing if 3 is not equal to 3,
and that's false. You also see Director returning 1 for true and 0
for false.
>I notice that when you make the design more robust you were
>actually writing more behaviors. And you are writing extra code
>to prevent so called as it were ' accidents' or accidental
>mistakes. Would this be equivalent to the is OKtoAttach handler?
Yes, its purpose is the same, and you would probably use the
foregoing in conjunction with isOKToAttach, not just one or the other
in isolation. To do that you'd test the see if the sprite the
behavior was being dropped on was a QuickTimeMedia member sprite; if
not, you would return false. A simple way to do that would be:
on isOKToAttach me
return sprite(me.spriteNum).member.type = #quickTimeMedia
END isOKToAttach
If the return was false, the user would not be able to attach the
behavior to the sprite.
--
Warren Ockrassa | http://www.nightwares.com/
Director help | Free files | Sample chapters | Freelance | Consulting
Author | Director 8.5 Shockwave Studio: A Beginner's Guide
Published by Osborne/McGraw-Hill
http://www.osborne.com/indexes/beginners_guides.shtml
[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!]
