At 05:31 +0800 04/18/2002, noelle cheng wrote:
>>>>>By the way, what is XML parser? What is the use of it in lingo?
>>>>>It modifies lists?
>>>>
>>>>It can read and modify XML-formatted data, if my understanding of
>>>>it is not faulty. I have not had occasion to really explore the
>>>>XML parser (I have never had to parse XML data), but I gather it
>>>>is quite useful.
>>>
>>>Does it cause the original data in a .dir file to go haywire?
>>
>>Not as far as I know.
>
>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". (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. ;)
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.
>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.
>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.
>Under what circumstances would it be used?
In a file I'm working on now I have a progressive draw of sprites on
the Stage. That way the program, as it loads, appears to "build"
itself onscreen. Only after all the sprites are visible do I attach
the behaviors, because only then am I ready for interaction from the
user. Meanwhile the program's had time to get itself loaded into
memory. This takes place over the course of five frames.
It would take as long for everything to draw to the screen at once
and all the sprites' behaviors to activate (in other words I could
just as easily do this in one frame rather than five), but the
progressive build gives the user something to watch while the program
loads -- this gives the impression that the program is actually
operating and, though it doesn't operate any faster than otherwise,
it *appears* to be working more quickly.
>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.
>How about identical scripts? Will they be executed twice?
If they have the same handler names within the same script member,
Director should complain.
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.
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.
> 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? 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.
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...)
>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.
>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.
>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.
>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. ;)
--
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!]
