At 21:11 +0800 05/13/2002, noelle cheng wrote:
>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?
That's correct -- since the movie has stopped playing, there's no way
for it to detect whether any further mouseUp events occur.
>> 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,
or when the user quites a projector.
>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.
>>>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?
I mean the save and save as commands in Director are for author-time
movie files only. What I was referring to in the book at that point
was a projector or Shockwave movie saving out information to an
external file, not anything available in Director itself.
>> 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.
>>>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?
To stop playback in Shockwave 'halt' is the preferred choice. The
advantage of using halt is that it stops playback in Director without
actually quitting the program, while in a projector it stops playback
*and* quits the projector.
>>>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.
>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.
>What are non-PPO languages? Are you saying that the trend is to
>start using OOP for Director programs?
I meant non-OOP. Sorry.
>>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.
>>>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.
>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?
What I said -- that instantiation of an Xtra is generally the way you
start working with that Xtra. Some Xtras do not require specific
instantiation, but generally they do.
>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.
>>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.
>>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.
>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.
>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
If you call this in the message window you'll see that 'var' is
treated as being "true", because its value is not 0.
--
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://shop.osborne.com/cgi-bin/osborne/0072195622.html
[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!]
