At 10:41 AM 4/18/2002 -0500, you wrote: >>So why does Director crash then? Because the PC platform is unstable? >>I've had the computer freezing when I need to do a save - many times. > >Well, while my knee-jerk reaction is to blame the platform, in reality >there are quite a few reasons Director might crash, most of them having to >do with "pilot error".
Do you mean that the user is at fault? >(And to be fair Windows, since 1995, has gotten better. In a few more >years it might even be as stable as DOS used to be. ;) You're talking about which one? Windows ME , XP or 2000? ME is very unstable. It freezes very often. >For instance if some other program has the XML file open at the same time >as you do, there might well be a conflict. Or if for some reason >Director's trying to write something to the XML file that it doesn't like, >unexpected behavior might result. > >>>You can handle XML parsing as you would any other type of data, to the >>>best of my knowledge -- for example you could use a behavior to do it >>>that resides across a sprite's span, or you could try a parent script, >>>or even a traditional movie script. You should be able to handle the >>>data either in a current movie, or via a MIAW, or by branching off with >>>a go to movie or play movie call. >> >>So we can import it into the main .dir with no problems? With no need for >>branching? > >As far as I know, but again, I haven't had occasion to play with XML yet, >so I'd have to defer there to someone with experience in the area. >>Use XML to store randomized lists to create a quiz, what else? > >I've seen filesystems defined using XML. As far as I can tell pretty much >any kind of data you want stored -- in any fashion you choose -- can be >put into XML format. Thank you for your through explanation. >>Could you elaborate on this, please? What are spriteless behaviors? > >Well, the frameScript can also be accessed with sendSprite ( 0 ), and when >you are doing Score recording, since you don't have the UI there to >prevent its happening, you can define a sprite, attach behaviors, and then >remove the sprite. Only the behaviors will be left behind. That's really >an error, but it can happen. So in reality, there are no spriteless behaviors? >>How is it possible to attach behaviors to only part of a sprite's span? > >Now you're making me think just how possible this is to do. I don't recall >if you have to actually split the sprite, or if you can just select a >range of frames to which to attach a behavior. This is another one you can >do in Score recording too, I believe -- make a sprite span 2 frams, for >instance, but only put a behavior on it in frame 2. Sorry, it was what you wrote in an earlier email which puzzled me and it set me thinking, trying to understand what you meant. >>For scripts ( behaviors or otherwise) which remain in the cast (and are >>cast member scripts) but not found in the score or on stage are they >>executed and compiled at run time? > >They are compiled -- well, tokenized, interpreted, bytecoded, what have >you, when the projector is made -- but unless they have some kind of >handler that executes with a file load (such as startMovie) they're >ignored until specifically executed. > >>In other words do *all * scripts in the movie get compiled and executed? > >No, and that's one of the lovely things about programming in general and >Director in particular -- you can have entire swaths of code sitting in >your file that is hardly ever used but, when it's required, is ready to go. Yes, that's what I wanted to know and I'm glad that it's there as it's very useful. >>How about identical scripts? Will they be executed twice? > >If they have the same handler names within the same script member, >Director should complain. Does it? >However I believe if you have (for instance) two separate movie scripts in >the same Cast, and each has a startMovie, Director won't indicate there is >a problem. I believe the *first* script will be the one to execute. The >second one with the other startMovie will probably be ignored. Yes, I know that - now. >Apart from that, no, you won't get two identical handlers with different >names executing twice. > >Regarding your cursor question -- if you're using an Xtra someplace, it >might be taking over and changing the cursor on its own whenever its >member or data is present. I'm not sure what you'd do about that; >hopefully the Xtra would have documentation covering this and would have >suggestions on how to handle it. Thank you. But all Director projectors have Xtras - I don't think you can have any without.So I search through all my Xtras? >> Even when I copied and pasted the quiz using XML into my main movie, >> which is to be made into a projector, it still refused to run. And all >> the globals had been removed. > >Well, this is an interesting statement. Did you copy/paste the XML data >into a script window? Interesting? I've done something wrong? No, I mean, I copy and paste the XML data into the internal cast. I copy and paste sprites into the score. > What I mean is XML data is just data. It's not code, it's not program, > it's not really anything except data. You have to pass it through some > kind of filter to interpret its contents and handle them appropriately, > respond to the contents, etc. The XML data actually consists of parser, tokenizer and the node. This is generic. I have to pass it through some kind of filter? >So what I believe you would be doing is using the XML parser to read data >into a variable in your Director code from an XML file resident on disk >someplace, rather than internal to your projector or movie. (Though I >could be wrong...) I don't understand what you mean. But there is an XML data file in my movie. >>Is there any possibility of an external QT midi file playing in the stub >>projector which is already an external file? > >Hmm, there might be some confusion here regarding the term "stub >projector". A stub projector is a projector that does only one thing -- it >loads a Director movie. Usually it has a single frame script: > > on enterFrame me > go to movie "whateverMovie" > end > >...whereupon it immediately loads that movie. The advantage of using a >stub is you don't necessarily have to re-compile your programm just to >release an update; you cna simply send out a noew movie file that replaces >the old one alongside the projector. > >However, generally, when one is creating a projector one is starting with >a more or less stand-alone Director movie. Once that has been made into a >projector, it is not necessary to distribute the projector with the >Director movie alongside it -- the movie is in the projector as part of >the package. > >In this situation, whenever you make changes to the Director movie, you >have to make a new projector as well. > >It seems from the sample you sent that you are using a stub projector to >load an external Director movie. And that is not correct? >>Why do stub projectors use the .dir command? > >Actually they don't need to. You could do: > > on mouseUp > go to movie "quiz" > end > >The projector becomes part of the playback medium in this case, >interpreting the data you've put into the Director movie in such a way >that the user's computer can understand and display it. Why are some movies known as .dir and others just simply movies? Surely there are diffferences between them? >>Are they not .exe files themselves? > >Projectors are, yes, but Director movies are external resource files. They >can be read by projectors (provided the projector has the requisite Xtras). > >Actually maybe that's where you're getting into trouble. Your original >projector might not have the XML parser Xtra included, which would make it >impossible for your quiz movie to do anything with XML data. In this case >you'd have to remake the projector in Director, starting first with the >Modify --> Movie --> Xtras... menu and making sure the XML parser was >included. Then you'd re-build the projector as before and see if it >behaves as you expect. It still doesn't work properly within the movie. There are too many internal errors. Maybe I'm wrong. I shouldn't be creating projectors? >>Frame scripts are spriteless behaviors? I don't understand. > >Yes, they're behaviors -- for instance you might see > > on exitFrame me > go to the frame > end > >...and 'me' is *always* a behavior telltale. Since the script exists in >what is technically channel 0, it can also be referred to as sprite 0 if >you are doing sendSprite calls to any code you might have put there. I use >frame script behaviors like this to control interactions with MIAWs. > >And you can have behaviors in the score that don't have sprites attached, >though that's generally an accident. ;) You mean they are mistakes or errors? Why is it that sometimes when I attach more than one behavior to a sprite, some behaviors don't work properly? For example, for buttons, there is usually a change cursor behavior, a rollover and a go to script. After I have compiled my script, the rollover may not work. But when I check the code, it's there. Even after deleting the sprite and re-attaching the code, there's still problems. How do I correct this? Thanks for taking the trouble to explain so many things. 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!]
