Hi,
At 10:15 AM 5/14/2002 -0500, you wrote:
>>> 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?
>
>No, I don't believe so -- this one just wants to be a movie script.
>
>>Anyway, the playhead head just went right past it without stopping.
>>Nothing appeared in the message window. What is supposed to happen?
>
>It's not a frame script. Thee isn't meant to be any playhead action. It's
>a cript that is meant to execute when the move stops playing; this can
>mean when you click the 'stop' button in the control panel,
Yes, a pop-up window appears with the word Quitting! When you press ok, the
window disappears.
> or when the user quites a projector.
Yes, the same thing i.e. a pop-up window appears with the word Quitting!
When you press ok, the window disappears.
>>What is the purpose of using �alert�?
>
>Just to show that the program knows something is happening. In a projector
>that's one of the few ways you can easily get an internal event to display
>some kind of external message.
Whar are the other ways?.
>>> 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?
>
>Because you have to. There is no other way to save user information except
>to write a handler that does so, saving out whatever information you want
>to retain.
So this is another use for custom handlers - to save information?
>>>>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?
>
>In an object, encapsulation is innate, yes. You have to go to rather
>extreme lengths to get past that encapsulation, in fact.
No one does this?
>>How does an object look for and squash errors?
>
>It doesn't. Your code makes it do so. The three-behavior version is a
>simple example of that.
Sorry, I still do not understand. I use the object so that I may make
use of its code for this?
>>What are non-PPO languages? Are you saying that the trend is to start
>>using OOP for Director programs?
>
>I meant non-OOP. Sorry.
Could you please provide an example of non-OOP language so that I may
understand better what you are trying to say? How does it look like?
>>>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?
>
>That's not something that can easily be answered apart from the phrase
>"with experience". With experience, an understanding of abstraction of
>data from interface will be easier for you.
But I still do not understand. Why is it that the more I 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!)
>>
>>You mean you create parent scripts that create object code from variables?
>
>No, that you create an instance of a parent script into variables. It's
>fundamentally the same concept as using an Xtra such as FileIO or FileXtra3.
>
>>When you write �in general� do you mean that sometimes the reverse happens?
>
>Yes, or that something is generally but not always true.
Is a parent script then somewhat similar to a movie script, i.e. as in the
pizza ship example,
on page 364,
'Since you're accessing the same shop object you made the first time
(oShop), the properties you set for the initial call has been
retained. They're now available anywhere,as many times as you want, as
many places as you want.'
>>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?
>
>No, it's because any computer capable of runing Director 8.5 has the RAM
>required to store a list of that size. Property lists don't occupy
>tremendous amounts of memory, which is helpful, and they occupy less than
>(for instance) #field members. So storing orders for a pizza shop in a
>property list is actually a pretty efficient usage of memory in Director space.
Are property lists the only way to store orders?
>>>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 ?
>
>Again, experience -- start with the stuff you've seen so far.
But I barely understand what you write... Aren't there any standards or
rules I may follow?
>>>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.
>
>Yes.
>
>>And it is the passive receptor that prevents script errors. Would
>>this normally be the case in this type of encapsulation?
>
>This is one way of doing it, but it's not by any means the "required" way
>of going about it.
What then are other ways of doing it? That is, passive receptors does not
always prevent script errors?
>>Do I substitute the code above for
>>
>> if sprite(me.spriteNum).member.type <> #quickTimeMedia then
>> exit
>
>You might be able to; try it and see what happens.
I substitute the code like this:
on AdjustVolume me, yMyDirection
on isOKToAttach me
return sprite(me.spriteNum).member.type = #quickTimeMedia
END isOKToAttach
if yMyDirection = #down then
sprite(me.spriteNum).volume = \
sprite(me.spriteNum).volume - 1
else
sprite(me.spriteNum).volume = \
sprite(me.spriteNum).volume + 1
end if
END AdjustVolume
is this correct?
Then I receive an error message saying:
script error : Handler definition expected
if ? yMyDirection = #down then
This did not occur when
>> if sprite(me.spriteNum).member.type <> #quickTimeMedia then
>> exit
was used.
Why is that? Rather the movie was able to play with no errors.
>>How is the return false? You just wrote earlier that �You also see
>>Director returning 1 for true and 0 for false.�
>
>1/0 and true/false are interchangeable in Director. In fact Director will
>allow anything to be tested as true if it has a nonzero value, unless you
>explicitly test for falsity. What I mean is:
>
> on TestDefault
> var = 3
> if var then
> put "var is TRUE"
> end if
> END TestDefault
The above is a test for falsity?
Sorry, where do I place this script so that I may receive the following
message? It is not a movie script?
>If you call this in the message window you'll see that 'var' is treated as
>being "true", because its value is not 0.
Thank you.
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!]
