Hi,
At 11:14 AM 5/10/2002 -0500, you 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?
Sorry, no, I believe that mouseUp handlers may be written into
behaviors. What I mean is that when a movie stops playing (because of a
halt or quit command), things like on mouseUp will also not execute? In
fact every handler written subsequently will not execute except for
endSprite events?
>>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
I opened a script window to do the above, and wrote the script. Could it be
written as a channel 0 script? Anyway, the playhead head just went right
past it without stopping. Nothing appeared in the message window. What is
supposed to happen?
What is the purpose of using �alert�?
>>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.
Sorry, but what do you mean?
> 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.
Why would you want to do that?
>>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.
So what should be used?
>>>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.
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.
Here I do not understand. What do you mean by object�s natural
encapsulation ability? Do you mean it is innate?
>>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.
How does an object look for and squash errors?
What are non-PPO languages? Are you saying that the trend is to start
using OOP for Director programs?
>What this is is abstraction. The more you abstract data from interface,
>the harder it is to break things.
How do I abstact data from interface? Is this what you mean on page 226?
So it becomes easier to use?
>>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!)
You mean you create parent scripts that create object code
from variables? Is this no different then from a movie script?
When you write �in general� do you mean that sometimes the reverse happens?
Yet you wrote in another email that � It's not the *only* way to do it --
some Xtras don't require instantiation, for instance -- but it's relatively
common.�
I sorry, but what do you mean?
On page 390,
�What�s more, the pizza shop is now truly scalable. �We�re not talking
about a couple dozen pizzas here; in fact you could place thousands of
orders here in a single application session for this program, and not run
out of memory.�
How does the program not run out of memory? Is this because of the use
of variables?
>>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.
How could I learn to write this ?
> if sprite(me.spriteNum).member.type <> #quickTimeMedia then
> exit
> end if
Thank you. I do appreciate your help. Yes, I was able to adjust
the volume softer or louder after I amended this.
Let me recap:
>This an example of adapting an existing behavior such that you have a
passive receptor of a message and an active sender -- and it also >helps
show how this kind of encapsulation should be able to help you avoid script
errors.
Here the active sender is the volume control button, right?
The passive receptor is the QT music sprite.
And it is the passive receptor that prevents script errors. Would
this normally be the case in this type of encapsulation?
>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.
Do I substitute the code above for
if sprite(me.spriteNum).member.type <> #quickTimeMedia then
exit
How is the return false? You just wrote earlier that �You also see
Director returning 1 for true and 0 for false.�
Thank you for taking the trouble to explain.
Noelle
[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!]
