Hi, At 11:45 AM 5/9/2002 -0500, you wrote:
>>>>Am I to understand that endSprite messages will always execute whereas >>>>all other messages will not? >>> >>>In general that is a safe thing to understnad about sprite events. At >>>the very least beginSprite will execute (when a sprite first makes its >>>appearance) and endSprite will as well. As for exitFrame and so on, >>>well, if the movie stops running (for whatever reason) before an >>>exitFrame event can occur, obviously the scripts associated with the >>>event won't run. >> >>Does this apply to other messages sent? > >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. >>Does this apply to other messages sent? >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? By the way, how do I define a stopMovie handler? 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? You also mentioned on page 220 that quit would not work in a Shockwave movie, so we shouldn't be using it? >>Why are there two endsprites before the playhead stopped? > >The only way I know of that can happen is if two copies of the behavior >were somehow attached to the frame, or to the Score someplace. I've never >seen a case of a single endSprite handler in a single behavior executing twice. I'm really am not sure... >>>>May I ask you something else? Remember when you were helping me with >>>>the visible and invisible sprites? >>>> >>>> The original commands refused to execute. Why was that? >>> >>>My suspicion would be because the original commands either were not >>>referring to the correct sprite number, or they were being overriden >>>somehow by another behavior that forced the sprites to be visible. >> >>How would they be overridden by another behavior? > >If behavior a says "Make sprite s invisible", and behavor b says "Make >sprite s visible", behavior a's command will be overriden by behavior b's >command, because b will execute *after* a. Thus you get one behavior >overriding another. > > >In the case of the volume buttons for your QuickTime audio things had to >be a little more complicated, because you needed to have volume arrow >sprites that affected another sprite's state. Now it gets tricky, because >if you happen to move the QuickTime audio sprite, the volume behavior will >break. > >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? Actually the purpose of OOP is to create objects and use them? But why do we need to create objects? There is no other way? What is the difference between a behavior and a parent script? Besides having to go to to the PI to modify the script to parent script else it won't run . (page 358) >You can try it yourself if you want. The basic way to do it would be to >change the behavior for the volume button so instead of this: > > on mouseDown me > me.AdjustVolume() > END mouseDown > >...it reads as this: > > on mouseDown me > sendSprite ( pnMySoundChannel, #AdjustVolume, pyMyDirection ) > END mouseDown > >You'd completely remove the entire "AdjustVolume" handler from this behavior. >You would then create a second, brand-new behavior -- just an empty script >window -- and create a modified AdjustVolume handler in it thus: > > on AdjustVolume me, yMyDirection > 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 > >This behavior you would then attach to the QuickTime audio (or movie) >sprite itself. > >What should happen is this. When you click a volume button, a message >should be sent to the button's target sprite, telling it to adjust its >volume, and passing a parameter to it -- in this case, the contents of the >variable pyMyDirection, which you recall you set using the PI or the >dialog box for the behavior. > >The acceptor behavior on the QuickTime sprite then receives this message, >and adjusts its volume accordingly. Yes, I tried it using on mouseWithin and it works. Thank you. 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? 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? >What makes a difference here is that if you move the QT sprite to a >different channel, the volume will not get adjusted -- but you will also >not get a script error, because since there would be no behavior in the >channel specified by pnMySoundChannel to accept the message, no attempt >would be made to adjust the volume on something that was not there to >begin with. > >If you are going to have only one QuickTime sprite on the Stage at a time, >you can make it even easier by removing the pnMySoundChannel property >entirely from the volume button behavior, and using sendAllSprites instead >of sendSprite: > > on mouseDown me > sendAllSprites ( #AdjustVolume, pyMyDirection ) > END mouseDown > >Only the QuickTime sprite will have a behavior attached to it that accepts >the AdjustVolume handler call, so only that sprite will attempt to adjust >its volume. Then you no longer have to care at all about what channel the >QuickTime sprite occupies. I did this as well. >This is 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. > >You can even modify AdjustVolume a little more to prevent errors in the >event it's accidentally attached to the wrong sprite type: > > on AdjustVolume me, yMyDirection > if sprite(me.spriteNum).member.type <> #quickTime then > exit > end if > 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 > >What happens here is the behavior first tests to make sure it's attached >to a QuickTime sprite. If it's not, it exits -- meaning the rest of the >command is not executed. This will have the effect of eliminating script >errors should the behavior accidentally become attached to a different >sprite type, such as a bitmap. 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? But it worked earlier without the test. What is the meaning of the <> sign? How does Lingo recognize this? >>If I did it according to the principles of object design, would not >>re-doing it result in writing better code? > >Well, look over the foregoing -- hopefully you can see that the new design >is a little more robust, but also hopefully you can see why I didn't start >with this approach immediately; you had to first become comfortable with >the idea of using behaviors at all, before you could look into the idea of >senders and receivers. 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? >>Do QT audio files run just once in a movie? The music plays just >>once through and stops even though there is a frame loop. Why is that? > >That's the default behavior for audio and video. You can set it to loop by >modifying the Cast member properties. Click the Cast member, then choose >the "member" tab in the PI. You should be able to mark it to loop there. Sorry, I think that there was no loop there. I did find a loop under 'Quicktime ' tab playback properties and ticked it as true. Then the music didn't stop playing but looped when it reached the end. 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!]
