At 23:18 +0800 05/03/2002, noelle cheng wrote:
>Are not these questions rhetorical?
Yes.
> I do understand what you mean. It is not necessary to use a few
>frames when one would suffice.
>
>However, if I wanted a sound file to finish playing how do I do it?
>
>I can�t use a frame script
>
>on exitFrame me
> go the frame
>end
>
>because it loops.
Quickest way would probably be to set a cue point in the tempo
channel, telling Director to hold on that frame until the sound was
finished playing.
>What is the purpose of using a timer in Director?
Um, timing things. ;)
>From the help file:
>
>If multiple timers are required, you must create and manage your own.(�)
>Typically, you use the ticks property to track time in this manner.
>
>Is this the reason why timers should not be used ?
There's no reason they shouldn't be used. There's nothing wrong with
timing things. Sometimes you have to time things. (Like if you are
making a quiz game and you want to give the user 30 seconds to answer
a question.)
>What is the difference between endSprite and exitFrame?
With a one-frame span you might not think it, but endSprite happens
only once -- when the playhead leaves the frame containing that
behavior. exitFrame happens, in essence, when the playhead is *about
to* leave that frame. So an exitFrame script that contains 'go to the
frame' will keep your playhead there until you explicitly send it
someplace else -- but also will *not* result in endSprite executing
until *after* the playhead has been ordered to go elsewhere.
Try this, for instance. Put the following behavior in your script
channel, spanning across perhaps half a dozen frames:
on exitFrame me
put "exiting frame"
end
on endSprite me
put "ending sprite"
end
...When you click play, you will see a half dozen frame-exit
messages, but only one endSprite message.
[Note: If you put the above into only one frame script channel, and
then copy and paste that so they *appear* to span across half a dozen
frames immediately adjacent to each other, you will get different
results. Try it and see, and think about what happened and why.]
Now if you modify the above a little, you'll get another result:
PROPERTY pnFrameCount
on beginSprite me
pnFrameCount = 0
END beginSprite
on exitFrame me
pnFrameCount = pnFrameCount + 1
if pnFrameCount < 6 then
put "looping frame"
go the frame
else
put "exiting frame"
go ( the frame + 1 )
end if
end
on endSprite me
put "ending sprite"
end
Put this into just one frame script channel and play. Again you will
see different results from what you've seen until now. Now span the
above script across several frames and play, and see what happens
then. Finally, copy and paste the above script into adjacent frames
so they *appear* to be spans of one behavior, but are not. Play
again. Compare the results.
This should illustrate how Director handles exitFrame events as
compared to endSprite events.
[Note: Instead of the line "go ( the frame + 1 )", you can put in the
word HALT (look the keyword up in the docs). Try it and see what
happens. How does this affect endSprite? *Does* it affect endSprite?]
>'You write a handler with the purpose of grouping a related set of
>programming instructions, which are meant to cause the computer to
>behave in a certain way. You can almost think of handlers being to
>programming what paragraphs are to writing.'
>
>From this, I gather that handlers are an integral part of programming.
Yes. In other programming languages they might be known as
subroutines or functions, but the principle is more or less the same.
>They normally begin with "on something" example "on MouseUp" and you
>can place many of them together on a single script. Am I correct?
Yes. The volume behavior, for instance, is a collection of handler definitions.
>OnGetPropertyDescriptionList is a system handler. What does this
>mean? So there are different types of handlers?
There are indeed. At minimum there are handlers *you* define, such as
the custom ones I made in the volume behavior; and ones that Director
is designed to recognize, such as frame, sprite and mouse events. Of
the latter I believe Macromedia has created several distinctions, but
I'm not sure how well defined those distinctions are.
>Would it be correct to say then that scripts are usually made up of handlers?
Yes; in fact you have to have some kind of handler definition for a
script to be a script.
--
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!]
