At 21:37 +0800 05/15/2002, noelle cheng wrote:
>>>What is the purpose of using �alert�?
>>
>>Just to show that the program knows something is happening. In a
>>projector that's one of the few ways you can easily get an internal
>>event to display some kind of external message.
>
>Whar are the other ways?.
They involve creating a projector that displays a message window at
runtime, or that writes message window output to a text file. That's
somewhat involved and not really important to know right now, beyond
knowing there are ways to get *some* information from a projector
regarding its internal processes.
>>Because you have to. There is no other way to save user information
>>except to write a handler that does so, saving out whatever
>>information you want to retain.
>
>So this is another use for custom handlers - to save information?
You can use custom handlers to do anything you need to do that
Director (or Director via Xtras) is capable of doing.
>>In an object, encapsulation is innate, yes. You have to go to
>>rather extreme lengths to get past that encapsulation, in fact.
>
>No one does this?
I believe those who don't have a complete understanding of OOP do so.
>>>How does an object look for and squash errors?
>>
>>It doesn't. Your code makes it do so. The three-behavior version is
>>a simple example of that.
>
>Sorry, I still do not understand. I use the object so that I may
>make use of its code for this?
No, you create code that traps errors. You can use that code in an
object, if you are doing OOP design.
>Could you please provide an example of non-OOP language so that I
>may understand better what you are trying to say? How does it look
>like?
Any code that takes place in a movie script is non-object code,
something that doesn't require instantiation, is not encapsulated,
and is generally globally available. The "TestDefault" handler I sent
earlier is such an example.
>>That's not something that can easily be answered apart from the
>>phrase "with experience". With experience, an understanding of
>>abstraction of data from interface will be easier for you.
>
>But I still do not understand. Why is it that the more I abstract
>data from interface, the harder it is to break things?
Interface is the means by which data is manipulated. If the interface
is mishandled, data can become damaged. Thus, the more abstraction
you have between data and interface -- the less *direct* access
interface has to data -- the less opportunity there is for that
interface, via accidental or deliberate mishandling, to corrupt the
data.
>Is a parent script then somewhat similar to a movie script, i.e. as
>in the pizza ship example,
>
>on page 364,
>
>'Since you're accessing the same shop object you made the first time
>(oShop), the properties you set for the initial call has been
>retained. They're now available anywhere,as many times as you want,
>as many places as you want.'
Not really -- it's a script instance contained inside a variable. Its
functions might be available for calling by its access methods, but
they have to be explicitly invoked. What's more, the data contained
and manipulated inside one pizza shop instance would be discrete from
data held inside another instance, even when that instance is being
created and handled in the sane Director movie. It's as though you
have two completely separate miniature programs running in your
Director movie.
>Are property lists the only way to store orders?
They are the most efficient way that is internal to Director (that
uses Director's own tools).
>>>>Not just that. You also write it as a form of error trapping, as
>>>>I did with the void tests. It doesn't hurt to confirm the
>>>>integrity of a variable before proceeding to work with it.
>>>
>>>How could I learn to write this ?
>>
>>Again, experience -- start with the stuff you've seen so far.
>
>But I barely understand what you write... Aren't there any
>standards or rules I may follow?
Actually surprisingly little. Lingo is a very loose language as far
as structure and syntax are concerned. If you're looking for
structure, to no small extent you have to either create your own or
adopt that of others. That's why I introduced and explained my own
set of conventions rather early in the beginner's guide.
While this lack of structure does make it easier to simply sit down
and start from nothing in Lingo, I believe it does make it harder to
learn if you've got a mind that prefers orderly handling of things.
If, for instance, you're a fan of symbolic logic, you might find
Lingo to be very chaotic.
>>>Here the active sender is the volume control button, right?
>>>The passive receptor is the QT music sprite.
>>
>>Yes.
>>
>>>And it is the passive receptor that prevents script errors. Would
>>>this normally be the case in this type of encapsulation?
>>
>>This is one way of doing it, but it's not by any means the
>>"required" way of going about it.
>
>What then are other ways of doing it?
After I'm done numbering the grains of sand on the beach I'll get
back to you on that question. ;)
>That is, passive receptors does not always prevent script errors?
That's correct. You can't plan for everything, for instance, and you
can't create perfectly bulletproof code, if the program is going to
do something of even moderate complexity. All you can really do is
try to introduce as much crash padding as possible.
>I substitute the code like this:
>
>
>on AdjustVolume me, yMyDirection
>
>on isOKToAttach me
> return sprite(me.spriteNum).member.type = #quickTimeMedia
> END isOKToAttach
>
>
> 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
>
>
>is this correct?
No, you have one handler defined within another. You'll want to
remove the isOKToAttach handler from within the SdjustVolume handler.
--
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://shop.osborne.com/cgi-bin/osborne/0072195622.html
[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!]
