At 21:18 +0800 05/01/2002, noelle cheng wrote:
>>Yeah, that'll do it all right. Pause suspends *everything*
>>including frame or stage updates.
>
>What are frame updates?
Any time anything changes on the Stage it's a frame update. When
Director's playback head is doing its frame cycle thing (exitFrame,
etc.) it's a frame update. 'pause' is more or less the runtime
equivalent of clicking the stop button in Director. (Though it's not
quite that either -- think of it as setting the tempo to 0.)
>Is it necessary to redraw the Stage immediately?
Only if you've paused. In general no.
>When is a MIAW backgrounded?
Any time it's not in the foreground. ;) For instance I have a program
that uses a MIAW to present a text editing window to the user. When
that MIAW is in the background (not in use), I don't want it cycling
through its frame scripts. No events are taking place of which it
needs to be aware, and nothing is happening that I want it to analyze
or test. Therefore to suspend all operations taking place in the MIAW
I pause it.
>How does it eat processor cycles?
The MIAW, even if it is not visible, is technically open. You can
send messages to it with tell window, for instance, and it might try
to do the things it normally does when it's open and active (such as
test for and intercept certain keystrokes). You don't want it doing
that partly because you could get interference between the MIAW's
commands and whatever your main movie is trying to do; and partly
because every time the MIAW does something, it takes chip cycles away
from other parts of your program.
>>OOP design is philosophical as much as it is anyhing else and I
>>think I can say with almost perfect confidence that in 50 years it
>>won't even be in use any more. I don't know what will replace it,
>>but something will.
>
>OOP design? What I mean is I know that it is related to parent/
>child scripts so the purpose is to go into complex programming
>isn't it?
No, it's more intended to compartmentalize programming tasks.
Inheritance and code objects and such are part of that and it can be
used for programming of any order of complexity; but the original
idea was to make cookie cutter code. Well, that's fine within a given
program's context, but from program to program you are still making
your cookie cutters by hand.
Ideally programmers would have tools like Lego blocks. Myriad shapes,
sizes and colors, and everything interlocks and can be used in
effectively infinite ways. The way we have things going now, it's
like every programmer has his own set of Legos, and generally cut
from the programmer's own mold designs -- so there's effectively no
way for us to play together. Your Lego blocks won't work with mine,
and vice versa, unless we agree on a standard. We are a LONG way from
having standards like that. ;)
>Actually, I think when you use the word philosophical do you mean
>the way things are being achieved or created and not so much a
>search for a general understanding of the values?
There's no difference between a general understanding of values or
the way things are being done. Things are done a given way because of
general understandings; and general understandings evolved because of
the way things were done. Doing embodies the search for meaning. More
accurately, doing is the answer to the question of meaning.
>>This is why programming can be so unfulfilling, if you want to
>>define your life around your work. (That's not a good idea anyway.)
>>You have to practice nonattachment to what you do. That's a rather
>>difficult concept for many to grasp, particularly the Western mind.
>
>Is this a difficult concept? After all, non attachment to all
>material things is the main thrust of the teachings of Buddhism,
>one of the major religions of the East.
Yes, but it's quite unusual to the Western mind to conceptualize. The
framework here is more supportive of the idea of establishing
personal identity, individuality, and gain over others. There is very
much a push for attachment. The religious base even supports this
with a deeply institutionalized belief in an indestructible soul or
atom of self. When you work from that frame of mind nothing is more
distressing than to imagine your "life's work" as dissolving away to
nothing before you have even died.
>What is the average life span of a program? Not even five years?
Depends. Some programs are not worth keeping more than five minutes.
;) The worthy ones are likely to be upgraded and maintained; they'll
last. Well, they'll last longer. I don't know what the current record
is for longevity but it's probably some component of a UNIX system,
and that would put it at no more than 33 years.
>So I studied about movie scripts for nothing? Is there nothing
>redeeming about them?
I still use them when I need to have a handler of absolutely global
scope. For instance I have a sprite-naming behavior that adds a pair
of functions to Director's suite, 'spriteName' and 'getName'. I acces
them as though they were Lingo keywords. The only way to do that is
to create and use a global movie script.
You can also use movie scripts to instantiate and maintain parent
object references. This makes objects super-global, available to
every movie running under that projector session, even if it's a MIAW
or something called by 'play movie' or what have you.
All script types -- parent, behavior and movie -- are absolutely of
merit. Each has its purpose and value. But I believe that a
de-emphasizing of movie scripts is not the worst idea; that is,
rather than a movie script being the *first* thing a relative novice
is taught, perhaps it could be the second, after behaviors.
> Do you recommend then that I should read module 12 first? Then
>module 13 , and work my way backwards?
No, the progression's suitable I think.
>To use it, I go to the Macromedia folder from C:\Program files. I go
>to the Director 8.5 folder to locate the Xtras folder. I place the
>FileXtra3 folder into this folder.
Yes.
>I close this then I return to the Director program. When I open up
>Xtras which is between Control and Windows, it is not there.
You won't see it there. Items in the Xtras menu are generally meant
to be things you insert into your Cast, such as (perhaps) a
transition Xtra. But the Xtra itself is present in memory, ready to
be instantiated and used.
To see what Xtras are present, you can type in the Message window:
showXlib
You'll generally see quite a list:
-- Welcome to Director --
showXlib
-- XLibraries:
-- Xtra: Mui
-- Xtra: fileio
-- Xtra: PRegEx
-- Xtra: FileXtra3
-- Xtra: CastControl
...etc.
To find out what a given Xtra can do -- whether it has an interface
you can address via Lingo -- you use the 'interface' command and
reference the item:
put interface ( xtra "CastControl" )
Then you get terse notation on usage:
put interface ( xtra "CastControl" )
-- "xtra CastControl
-- by Paul Farry([EMAIL PROTECTED])
new object me
-- CastLib Maintenaince Handlers --
* AttachCastLib string name, string path -- Attaches an External
Castlib to the current movie
* DetachCastLib any castlib -- Detaches an External
Castlib from the current movie
"
Usually the Xtra will come with documentation that goes into more
depth than the 'interface' return. 'interface' is really meant to be
notes more than an exhaustive description.
--
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!]
