DreamLight Director Talisman

[Update: 10/31/01 As of Director 7, Macromedia discontinued the Learning Lingo manual rather than correcting and updating it. Too bad, since it was a valuable learning tool, as long as you had this list of corrections. If you are trying to learn Lingo, see if you can dig up an old copy of the D6 Learning Lingo manual, print out this list of corrections, and you’ll have a jump start to learning Lingo.]

I started reading the Learning Lingo manual to see what was new in Director 6. D6 is pretty cool by the way... This manual however... well, let’s just say it needs a little more work. ;-) The last time I read this manual (earlier edition obviously) was about 7 or so years ago ( I forget exactly when, it’s been a long time...) when Lingo was first introduced. No wonder Director is hard for newbies to learn. I had no idea that all this old stuff was still incorrect in the manuals. Ouch! ;-)

So it’s for all you newbies out there just starting to learn Lingo and relying on the Learning Lingo manual that I have put together all these corrections to the manual. This is also a way for me to sharpen my own Lingo skills (I’ve been busy doing 3D character stuff for the past few months) while learning the exciting new Lingo commands in the newly released Director 6.

I don’t claim that this is an exhaustive list of corrections or that every one of my corrections is entirely without error (Take this as a disclaimer that neither DreamLight nor I take any responsibility for this document. It is provided as-is without warranty of any kind. It was simply created for the well-being of the Direct-L community). I do however think that these corrections and clarifications to the manual could be of tremendous help in your efforts to learn Lingo. I sure wish I had something like this when I first learned!

Enjoy, Michael Scaramozzino President and Creative Director

Director Tips & Tricks

PS. I would like to thank the following for sending me additions to this list.
Denis Wieger, A3W_Multimedia@compuserve.com http://www.a3w.de/Lingo/Ldoc_MIAWs.html

Contents

• Overview
• Chapter 2: Script Basics
• Chatper 3: Working with Navigation
• Chapter 4: Troubleshooting
• Chapter 5: Controlling Score Channels from Lingo
• Chapter 6: Manipulating Sprites
• Chapter 7: Working with Fields and User Input
• Chapter 8: Controlling Sound and Digital Video
• Chapter 9: Creating User Interface Controls
• Chapter 11: Movies in a Window
• Chapter 12: Parent Scripts and Child Objects
• Chapter 13: Authoring from Lingo
• Chapter 14: Shockwave, the Internet, and Lingo
• Chapter 15: Authoring Behaviors

Chapter 2: Script Basics

Note:

These corrections are from the Learning Lingo manual. However, the printed Lingo Dictionary is not in the same order as the Lingo pop-up list for inserting lingo into scripts. The manual dictionary puts all "on" handlers under "o". The pop-up list sorts them by the second word. I'd prefer if both the pop-up and printed manual used the second word and ignored the "on" during alphabetizing. At least they should both be ordered consistantly anyway.

Page 21: Authoring behaviors

getPropertyDesriptionList

should read:
getPropertyDescriptionList The "c" is missing.

Page 29: if...then...else structures

"if sprite 1 intersects 2 then alert Move Over"

should read:
if sprite 1 intersects 2 then alert "Move Over"

Page 31: First sentence, second paragraph

The on rollOver handler frist assigns the value of rollOver to a variable and then tests the variable.

should read:
The on rolloverTest handler first assigns the value of rollOver to a variable and then tests the variable.

rollOver and rolloverTest are two distinct elements. rolloverTest is a user defined handler and rollOver() is a Lingo function.

Page 31: Second example

The example given, of testing a member for a size greater than 500K, is not appropriate for a case statement. It would be better suited to a simple if ... then statement since you are only testing one condition. I would suggest adding at least one additional condition to make it more appropriate as a case statement.

The example is also incorrect as written and will not run. The first line needs to end with the word of and >500000 is not a valid expression. Also, 500K is 512000, not 500000.

The example must be rewritten to function as expected:

case (the size of member whichMember > 512000) of 
   TRUE: preload member whichMember
   otherwise nothing
end case

The parenthesis seem necessary or the case gets confused with the first "of." It wouldn't run without the parenthesis.

Let's not confuse beginners into which type of statement to use in which type of circumstances. This is an inappropriate and hard to follow use of a case statement and would be much better expressed with the if ... then statement as follows:

if the size of member whichMember > 512000 then preload member whichMember

Therefore, I would either dispense with this example entirely or come up with a more appropriate use for using such a condition as a case test expression.

end case: On-line help

During these tests I also found an incorrect script example under the "end case" entry in the on-line Lingo help.

The example handler will not run as written:

on keyDown
   case the key
      of "A": go to frame "Apple"
      of "B", "C" :
         puppetTransition 99
         go to frame "Mango"
      otherwise beep
   end case
end keyDown

It should be rewritten as follows:

on keyDown
   case the key of
      "A": go to frame "Apple"
      "B", "C" :
         puppetTransition 99
         go to frame "Mango"
      otherwise beep
   end case
end keyDown

Page 31: Right column, second paragraph, last line

the keyPress

should read:
the keyPressed

Page 32: Figure

The figure is incorrect. The example and discussion goes from 10 down to 1 however the figure only goes from 10 down to 2.

Page 33: Right column, third paragraph, first line

Should read:
You can also use the set...to construct to assign a value to a variable.

I'd also add the put...into construct here, especially since you start using that construct with no explanation on page 34 and later.

I'd also refrain from naming example variables with the prefix the. This can get confusing for beginners since the prefix "the" is usually used to signify property names such as the keyDownScript, etc.

Page 34: Examples

On page 33 which explained how to assign values to variables the only commands mentioned were the set.. = and the set...to constructs. There was no mention of using put...into. On page 34 however in both global variable assignments, the put...into construct is used. This is going to be very confusing to beginners at best. Either you should introduce the put...into construct on the previous page, or change the examples on page 34 to use the set...= construct.

Chapter 3: Working with Navigation

Page 46: Right column, fifth paragraph

It's backwards. You are just now introducing the play command.

should read:
Note that all the ways that can specify a location with the go to command also work with the play command.

Chapter 4: Troubleshooting

Page 56: Right column, second to last paragraph, last line

The description of the Step Into button is not very clearly explained. It gives the impression that it just runs the nested handler and only stops at the next line in the current handler. It should be reworded like this:

The debugger stops at the next line of Lingo within the nested handler.

Chapter 5: Controlling the Score Channels

Page 62: When to make a sprite channel a puppet

When to make a sprite channel a puppet is not entirely clear. The last paragraph on the left column states the following:

The following sprite properties require the channel to be under Lingo's control before Lingo can modify them:

Page 62 & 63: Examples

Some of the examples seem to come from earlier editions of Director. The text clearly explains that the syntax for puppetSound is as follows:

puppetSound 2, member "Crickets" of castLib "Animal Sounds"

Then the next example reverts to the old syntax without any explanation. If this is intended to show the shorthand version of the command it should really be explained with emphasis that the channel being puppeted defaults to sound channel 1. This is especially true later when you show the command to stop the sound as puppetSound 0. Again, no channel is specified... This means that the puppetSound 0 will stop a puppetSound that happens to be playing in channel 1. This also means it will NOT work with the earlier examples which puppeted sounds into channel 2.

The easiest fix for this would be to rewrite the example at the end of page 62 as follows:

on mouseUp
   puppetSound 1, "Crickets"
   go to "Scene 4"
end

Even though the "1" is not really necessary, it will be much easier for a beginner to understand, since it follows the syntax of your earlier example and is more consistent.

I would then rewrite the puppetSound 0 on page 63 as: puppetSound 1, 0

Page 64: Left column, first bullet

The section that explains puppetTransition time should mention that the number reflects 1/4 seconds! This is important because ticks are used for some of your time measurements with other commands.

Page 64: Right column, second to last paragraph

When it's suggesting putting the puppetPalette command in the frame preceding the frame that the new palette is used in, it should mention to do this in the on exitframe handler. It should also mention that any puppetPalettes placed in on prepareFrame handlers are ignored. (Is this proper behavior. Lingo seems to ignore them in on prepareFrame, which seems to be a more appropriate place to put them... or is this a bug?)

Page 65: First paragraph

Why is it suggested to use puppetPalette 0 before doing a new puppetPalette? Is this related to the old puppetSound Windows bug where sounds were locked in RAM unless explicitly released prior to playing new sounds? I don't seem to need to issue puppetPalette 0 on the Macintosh before issuing a new puppetPalette. The new palette just takes control over any previous palette. Am I missing something?

Chapter 6: Manipulating Sprites

Page 68: Left column, fourth paragraph

Turning off the moveableSprite property is confusing. It should be more clearly stated as follows:

set the moveableSprite of sprite whichSprite to FALSE

Where whichSprite is replaced with the sprite channel.

Page 71: Left column, third paragraph

The sprite channel will be auto-puppeted if not already under lingo control.

Page 71: First example

The numbers 250 and 300 are backwards. The text says 250 is the vertical and 300 is the horizontal coordinate. For this to be true the example must be reversed as follows:

point( 300, 250 )

Page 71: on MouseDown example

The example is wrong. It has three errors and should be rewritten as follows:

on mouseDown
   set the loc of sprite 9 to point(the mouseH, the mouseV)
   updateStage
end

The word point was missing, the H & V components were backwards and the right parenthesis was missing.

Chapter 7: Working with Fields and User Input

Page 74: Table of properties

scrollTop of member has nothing to do with size as described. This setting aligns an area of the scrolling field to the top of the visible field. It is a positional alignment, not a size adjustment.

Page 75: Right column, second bullet

Should read:
The Score allows you to make a field sprite editable in selected frames by turning on the Editable check box at the top of the Score window.

Page 77: Right column, example

The example is incorrect. The word the in front of field must be deleted or it will not run...

Page 78: Left column, sixth paragraph, first line

It's backwards... They were already introduced to the set command and are now being shown the put command. It should read as follows:

Use the put command in much the same way that you use set to assign a string to a field cast member or other string, but use different syntax.

Page 79: Left column, second example

It's incorrect. Must delete the word the in front of lastKey in the case statement. It's a simple variable, not a property. I guess using the not only confuses beginner's as I mentioned previously, but whoever wrote the manual as well... this is at least the second time this error has cropped up. ;-)

I'd also suggest changing the variable name since there is indeed also a the lastKey property. However, the lastKey property returns the time since the last key, not at all what the example is trying to test!! ;-)

I'd rewrite the example as follows:

set whichKey = the key
case whichKey of
   "S": go to "Start"
   "H": go to "Help"
   "Q": go to "Quit"
end case

Note: I've also changed the action of the Q key from immediately quitting, to branching to the "Quit" label. We typically suggest this so that the movie has a chance to clean up anything necessary and allow a credits display. This makes testing easier since the movie doesn't quit Director every time you test the Quit key, it simply branches to the quit section. If the Quit section is the last section of the movie, it will simply stop on the last frame when testing rather than quitting Director. Under a projector however, it will quit the projector after the last frame.

Page 81: Left column, text & example

The text states that the example advances the playback head to the next marker if the cursor is over sprite 25. This is not true.

The example sets a variable called clickedSprite to whatever the rollOver value is at the time the exitframe runs. It then checks again if the clickedSprite is still being rolled over and if so it goes to the next marker. This has nothing to do with sprite 25... and actually doesn't make much sense to me as an example anyway.

Sometimes, as in the examples in the Lingo Dictionary, it's a good idea to put a changing value into a variable so you don't need to worry about it changing if the handler takes time to run. This is especially true if you need to make multiple tests on the same value such as in a case statement. You don't want the value to change before you are done with it. However, if you are only testing a value once in a simple if statement, I see no need to use temporary variables.

The example should read as follows:

on exitFrame
   if rollOver( 25 ) then go next
end exitFrame

OR

on exitFrame
   if the rollOver = 25 then go next
end exitFrame

I would further suggest that you use the following syntax for specific purposes (I know Lingo doesn't care but it's really confusing for beginners when the same function does different things at different times. Beginners aren't used to overloaded functions...especially without any explanation!)

the rollOver
should be used for testing which sprite the cursor is currently rolling over.

rollOver( whichSprite )
should be used for testing whether the cursor is currently over a specific sprite.

Again, this is not enforced by lingo but really makes things much less confusing. If you don't beleive me, why did whoever wrote the manual get confused? Besides, this is the way the examples in the Lingo Dictionary use the syntax as well.

Page 81: Right column, last example

Though technically not incorrect, I would present this example in one of the following two ways...

on mouseDown
   if the doubleClick = TRUE then openWindow
end

OR simply

on mouseDown
   if the doubleClick then openWindow
end

Using the test "the doubleClick = 1" works, but is not as intuitive as either of the other two methods. Sometimes beginners don't remember that TRUE = 1.

Page 82: Last bullet

The word the in the timeOutScript should be in the code typeface. It is part of the statement as it is in the first bullet...

In general the text is haphazard about putting the word the in the proper code typeface when discussing properties such as the movieTime of sprite sometimes you will see the word the in normal face and sometimes in code face which it should be when used with properties... I'm not going to point them all out since it's getting tedious. So any beginners out there, if it's a property they are talking about, the word the is usually part of the Lingo statement, otherwise it's just part of the text.... (MM, when re-editing this manual I'd suggest going over each use of the before a property and applying the proper typefaces as outlined on page 7 of the manual... ;-)

Chapter 8: Controlling Sound and Digital Video

Page 87: Left column, third bullet

Incorrect. It should read:

Test and set a specific channel's volume by using the volume of sound property.

Page 87: Right column, example

The example in the book attempts to set soundRecord (poor variable name since it is not recording a sound but rather storing a volume setting) to the volume of whichChannel which is trying to set it to the volume of a specific channel. However, then the example sets the soundLevel which is the "machine's" overall level, not the channel's volume. Even so, the statement trying to use the "volume" is incorrect and missing the word sound before the channel number!

The example also completely ignores the channel that the user wanted to play the sound in and simply plays it in channel 1, squishing anything that may already be puppet playing there...

It then tries to set the overall machine soundLevel to what the individual sound channel was originally set to. That's interesting since the soundLevel can range from 0-7 while the volume of sound can range from 0-255. So overall, this example is a complete mess!

The example should be rewritten as follows:

on playThunder whichChannel
   set oldVolume = the volume of sound whichChannel
   set the volume of sound whichChannel = 255 

   puppetSound whichChannel, "thunder"
   updateStage

   repeat while soundBusy( whichChannel )
      nothing
   end repeat

   set the volume of sound whichChannel = oldVolume
end playThunder

Of course the paragraph that follows the example is incorrect as well. It should be rewritten as follows.

This handler first saves the current volume of a user specified sound channel. It then sets that channel's volume to the maximum of 255. It plays the thunder sound in the specified channel and when done returns the volume of the channel to its original value. The repeat loop allows the sound to finish before the sound level is returned to its original value.

Please note that this does not effect the overall soundLevel of the machine itself. If that is set to 0, then you still won't hear anything. But the example the way it was originally written (if it was written correctly) would have raised the volume of ALL sounds playing, not just the thunder as they set out to do in the text... Note that unless you had already lowered any of the sound channels, this handler will have no apparent effect since every sound channel actually defaults to 255. ;-)

Page 90: Examples

Synchronization Examples are incorrect. I have rewritten the example to follow the book's conventions (such as prefixing all globals with "g"), fixed incorrect comments and variable names, and encapsulated it in a handler for beginners to follow a little better. The variable names and comments were incorrect. They say that ticks per second are being used when they really mean ticks per FRAME are being used... Also, there was a space in start Timer it should have been one word startTimer and will not run as written.

The example can be placed in the movie script and it should be rewritten as follows:

on startAnimation fps
   -- fps (frames-per-second) is passed to the handler as a parameter
   global gStartFrame, gTicksPerFrame

   -- Convert frames per second to ticks per frame
   -- there are 60 ticks in one second
   set gTicksPerFrame = 60 / fps

   startTimer
   set gStartFrame = the frame + 1
end startAnimation

Note, It's not a good idea to put the go to frame command in this start handler as suggested in the text. It can lead to possible infinite loops. In low fps settings it may actually jump to the frame it's already in, which will then reset the timer again and bingo... infinite loop. I'd also suggest setting gStartFrame to the frame + 1 which is the actual start frame of the animation, remember we invoke this from the frame before the animation. Otherwise you can still be pulled into an infinite loop on low frame rates... ;-)

It can then be called from the frame immediately before the animation starts like so:

on exitFrame
   startAnimation 10
end

The number 10 can be set to whatever frames per second you like. It is better to pass a value like this if you intend to try different values. That way you don't need to keep editing the internal functionality of the lower level handler startAnimation and can simply call it with different values. This also enables you to use the same handler for different sequences of animation synchronized to different rates.

The next example in the book is also incorrect. If called from the enterframe handler as shown, it will first draw this frame and then may jump BACK a frame under low settings. This leads to animation glitches. It should be called from the exitFrame or prepareFrame handlers and rewritten as follows:

on exitFrame
   global gStartFrame, gTicksPerFrame
   go to frame gStartFrame + ( (the timer) / gTicksPerFrame )
end

This type of synchronization is best used in simple animation sequences rather than sequences that have heavy Lingo interactivity (unless you are very careful). Since it may skip around within the sequence, you never know exactly which frames will be played and which won't be played... Also note that when fps is set pretty high, the playback head may jump off the end of the animation to further frames in the score than intended. I'll leave implementing a check for this over-run situation to the student as an exercise. ;-)

Page 90: Right column

The examples that show how to wait for a QT movie to play are inconsistent and seem overly complex. First off, one of them uses the memberNum of sprite 5 while the other uses the member of sprite 5. While both of these will technically work, it makes it more difficult to follow the examples. Also, why are we using the duration of member by locating the cast member of the sprite when we can simply test the sprite itself?

I'd rewrite these examples as follows:

if the movieTime of sprite 5 < the stopTime of sprite 5 then 
   go to the frame
end if

Then the "optimized" versions would be:

on exitFrame
   global gMoovLength
   set gMoovLength = the stopTime of sprite 5
end

and...

on exitFrame
   global gMoovLength
   if the movieTime of sprite 5 < gMoovLength then 
      go to the frame
   end if
end

However, I haven't run performance tests to see if this would save any time at all. Since the stopTime of sprite is a property setting I would guess that accessing it would be rather quick. Has anyone benchmarked this?

Chapter 9: Creating User Interface Controls

Page 96: Right column, sample menu

Though this is technically not incorrect, it is not a good way to implement a volume menu. If it were a navigation menu, then using go to frame commands would be fine but it's a little weird handling volume this way. Personally I wouldn't suggest using different frames for "logical" elements. I typically suggest using frames in more of a visual sense and handling strictly logical elements right in lingo without jumping all over the score.

A better example would be to call a handler that sets the volume directly, passing a parameter to it.

menu: Volume
Loud | setVolume( 7 )
Medium | setVolume( 4 )
Soft | setVolume( 1 )
Mute | setVolume( 0 )

Then I'd define the setVolume handler in a movie script as so:

on setVolume howLoud
   set the soundLevel = howLoud
   beep
end

Page 97: Left column, second paragraph, last line

This line should be rewritten as follows:

Note that if the custom menu uses keyboard shortcuts, they override Director's. Any of Director's shortcuts that conflict with the custom menu won't work while the custom menu is in effect. Director keyboard shortcuts that do not conflict, still function as usual.

(On the Macintosh anyway, I haven't tested this on Windows)

Page 97b: Right column, fourth paragraph

The text mentions "overlaying" two bitmaps for a cursor. I beleive it is talking about creating a "mask" for the cursor. I would reword this as follows:

To use a mask for the cursor, specify the cast members in the list as follows:

cursor [ cursorCastNumber, maskCastNumber ]

See the Lingo Dictionary for more information about cursor masks.

Chapter 11: Movies in a Window

Page 106: Right column, examples

First example should use gNewWindow as the global variable name to remain consistent with the suggested naming conventions for globals.

The second example is incorrect and will not run.

The third line of the example, set newWindow to window "theMovie" sets the newWindow to the string "theMovie". What was intended, was to use the file name stored in the variable called theMovie. I would also use a "g" in front of the globals and avoid using the as part of a variable name. the is already causing enough confusion throughout the manual.

The second example should be rewritten as follows:

on beginNewMovie movieFile
   global gNewWindow
   set gNewWindow to window movieFile
   set the titleVisible of gNewWindow = FALSE
   open gNewWindow
end

Page 106-107: Creating a sample movie in a window, last two paragraphs

These paragraphs are in the wrong place. They do not refer to the example we just examined but to the example before that one which uses a rectangle. These should be placed immediately after the first example on page 106.

Page 107: Right column, third and last paragraph

The third paragraph states that numbers 6, 7, 9, ... etc. have no effect when specifying window type. This is not true, using these numbers sets the window type to the specified number which happens to be equivalent to some of the other types, so it does have an effect, but it may be an undesirable effect.

The last paragraph states windowType defaults to 0. However, if I create a new test window and run put the windowType of window newWindow, I get -1. This seems to be the same style as 0. I mention this because if you write a script that tests for the value 0 (expecting it as default) you may be surprised.

Gretchen's page at http://www.updatestage.com/idlt06.html has a nice graphical list of cross-platform windoids: "The Standard Window Types." It shows functioning types of -1, 0, 1, 2, 3, 4, 8, 12, and 16.

Page 108: Left column, fourth paragraph

The text states:

... you can include the element pathName and a relative path reference to refer to a movie.

It should also mention that if this is done on the same line as the open command, the entire expression must be enclosed in parenthesis as follows:

open window ( the pathName & "fileName" )

Where "fileName" is replaced with the actual file name. This holds true on many commands that expect only one parameter. See the Lingo Dictionary under ()(parenthesis).

Page 109: Right column, second example

Incorrect the first line should read as follows:

set aRect = rect(0, 0, 200, 300)

As written, the example was trying to use a list. It should use a rect as in the example above it. Though a list tests equal to a rect using the "=" operator, the drawRect will not function properly if passed a list rather than a rect...

Also, the last sentence of the paragraph preceding this example should be rewritten as follows:

For example, these statements set the variable aRect to a rectangle, and then apply that rectangle to the window's drawRect.

Page 110: Right column, example

This example is not technically incorrect but is more convoluted than necessary. It is used as an example of using a multi-line tell handler but if you examine the handler you'll notice it doesn't make much sense. Why would you tell the window "Help" to make the window "Help" visible when you could more easily do that from the stage? A better example would be to tell the window "Help" to do things that only it can do such as manipulate its own field members such as this...

on mouseEnter
   tell window "Help"
      go to frame "Glossary"
      put "search item" into field "searcher"
   end tell
   set the visible of window "Help" to TRUE
end

This handler tells the help movie to go to a certain frame and put a string into one of its fields. The handler then makes the window visible (from the stage). Then if the searcher field is editable the user can edit its contents to perform their search.

Chapter 12: Parent Scripts and Child Objects

Page 116: Examples and discussion

These are not technically incorrect but they are not very good examples of child scripts. I know that the "advanced" version is better but that is really no reason to show examples that use less than optimal use of parent/child capabilities when those capabilities will actually simplify the examples. I'd let the child keep track of its own sprite channel.

I would also follow the suggested convention about using "g" for global names. I'd even go one further and suggest a convention for object property variables of prefixing them with "my". This prefix helps users get into the feel of treating objects as true entities with their own properties and handlers.

Also notice that I'm not using the overly verbose syntax of "the propName of me". This syntax is only needed when accessing ancestors properties. For simple parent scripts without ancestors it is not necessary and can cause confusion.

I would rewrite the examples as follows:

--Ball Parent Script
property mySprite, myHorizPos, myStageWidth 

on new me, whichSprite
   -- store mySprite, passed to me as whichSprite
   set mySprite to whichSprite

   -- give Lingo control over mySprite
   puppetSprite mySprite, TRUE

   -- position the mySprite on the stage
   set myHorizPos to 200
   set the locH of sprite mySprite to myHorizPos
   set the locV of sprite mySprite to 120

   -- store myStageWidth so I don't recalc it on every move
   set myStageWidth = the stageRight - the stageLeft 

   return me
end new

on moveBall me, direction
   set myHorizPos to direction * 50 + myHorizPos 

   if myHorizPos > (myStageWidth + 99) then 
      set myHorizPos to 0
   else if myHorizPos < -99 then
      set myHorizPos to myStageWidth
   end if

   set the locH of sprite mySprite to myHorizPos
end moveBall

--Here is the calling handler

on createBall
   global gBall1

   -- pass sprite #2 to the child object to take control of
   set gBall1 = new( script "Ball Parent Script", 2 )
   set the visible of sprite 3 to FALSE
   set the visible of sprite 4 to FALSE

   repeat with n = 5 to 8
      set the visible of sprite n to TRUE
   end repeat
end createBall

I would then use these examples on the following pages as well...

Page 120: Examples and discussion

The text on this page seems to have been taken from an earlier "tutorial" edition. It refers to scripts that "you wrote earlier" and "Save your work." Since this is no longer presented as a "tutorial," I would remove these references.

Also the word statement in the last line of this page should be in normal face since it is not part of the Lingo statement: set ball1 = VOID

Again, I'd also prefix ALL uses of global variables throughout the manual and examples with "g" as was recommended much earlier in the manual. It's a good recommendation, let's lead by example and follow our own suggestions... ;-)

Page 121: Controlling a child object

If our new Parent script was used, I'd rewrite the mouseDown scripts as follows:

on mouseDown
   global gBall1
   moveBall gBall1, 1
end

on mouseDown
   global gBall1
   moveBall gBall1, -1
end

Page 121: Using multiple objects

A good use of parent scripts that is not mentioned in the text is to encapsulate properties and handlers for easier organization and access. This also keeps our global name space from getting all cluttered up with "g" this and "g" that. We typically only use a few true global variables which typically refer to global objects. All the rest of our variables are property variables of one global object or another... Here are a couple examples.

We typically create an object called gMovieMan which is a global movie manager object. This enables us to store property variables and handlers that are then available to all subsequently branched to movies. We place common handlers here that handle file IO, memory management, etc.

We also create an object called gSoundMan which is a global sound manager object. This then contains and controls a set of soundChannel objects that directly control the individual sound channels.

So don't just think of child objects for animated sprites but think of them as intelligent objects that can be used for almost anything. They each know certain types of information and they can perform their own actions with that information.

Page 123: Left column, last line

Should read:

set the ancestor of me to new( script "Overall Condition" )

Page 123: Understanding the movie script

The puppetSprite command is being used in the on prepareMovie handler... This is not incorrect but I prefer to use puppetSprite mySprite directly within any child objects that need to take control of a sprite. As shown in the earlier example I rewrote.

This way you are letting the object itself take control and do things on its own rather than performing some functions in the movie scripts and only limited functions in the object itself. Anything that an object can do for itself, it should be allowed to do... Empower those objects, don't cripple them... ;-)

Page 124: Right column, example

The second "add" line is missing a closing quote and comma after the script name. It should read as follows:

add( ballList, new(script "BW Parent", count(ballList) + 1))

There is also a leftover global variable that is not used ball1. Again, I'd prefix all globals with "g" as well...

Page 125: Right column, example

No problem on this page but here's a note about additional information. There is a full thread on managing the actorList on the Director Talisman.

Chapter 13: Authoring from Lingo

Page 128: Left column, last example

If typed in as shown you'll get an error. The curly braces were probably there to signify an optional parameter but I have not seen them used anywhere else in the manual and they simply create confusion.

Should read:

new( type ) or new( type, member whichCastmember of castLib whichCast )

Page 129: Left column, last example

Not technically incorrect but personally I'd refrain from using gVideoMember as a global but rather simply return a pointer to the new member. I suggest this because it is more likely that the digitalVideo member is only needed temporarily if importing many cast members. If it's needed for more long term use it's also likely there are many more cast members we need to track in which case each new cast member could be put into a managed list rather than all using a single global variable.

It could be done like this...

on newDigitalVideo newName
   set newVideo = new(#digitalVideo)
   set the name of newVideo = newName
   set the crop of newVideo = TRUE
   return newVideo

This way if any calling handler needs additional access to the new video member they can simply call it like this...

set aVideo = newDigitalVideo "videoName" 

Then you can do whatever you like with aVideo without being forced to clog up the global name space with unnecessary globals. Or, you could use something like this if you need to track a bunch of them...

add gVideoList, newDigitalVideo "videoName" 

where gVideoList is a global list... It's a little more flexible this way.

Chapter 14: Shockwave, the Internet and Lingo

Page 138: Right column, last example

As we've seen many times already in this manual it's not a very good idea to use the as a prefix for your variables. It leads to confusion into thinking they may be properties... theNetID is too easily mistaken as some bogus Lingo property called the netID It leads to confusion for newbies so I would avoid it in a "learning" manual for beginners. ;-)

Page 139: Right column, downLoadNetThing

The description of downLoadNetThing refers to testing whether the preloading has completed, that should be testing whether the downloading has completed. Also it states it's disabled in a Shockwave movie playing in a behavior. This should read that it's disabled in a Shockwave movie playing in a browser.

Page 142: frameReady discussion

It should be mentioned that this tests for all cast members located in the score for a specific frame or range of frames. It does not test for castmembers that may be loaded under Lingo control. Unless you use frameReady() to test if the entire movie has loaded. Lingo loaded castmembers would need to be tested separately using the mediaReady of member property. This would be the case if you used a lingo controlled button that showed some other media member when clicked.

Chapter 15: Authoring Behaviors

Page 154: Right column, fourth paragraph

The text states "and then displays the reference number contained in me for this instance of the behavior"

I don't see anything in the handler example that would do that... Creating a new behavior with that handler changes the color but does not display a reference number anywhere. So either the text is incorrect or the handler is missing something...

Page 156: Left column, first example

The first example confuses the issue more than it clarifies, since it's missing the addProp command and the name of the list being added to.

A behavior's properties are nothing more than properties of a property list. For each behavior property the associated value is nothing more than a property list itself that contains a list of that particular property's attributes.

A behavior's property list can be built directly or by adding individual properties to an empty list. Then this resulting property list is simply returned by the on getPropertyDescriptionList handler.

A simple single property list could be created like this:

on getPropertyDescriptionList
   return [ #movement:[#default:5,#format:#integer,#comment:"Speed", ¬
                       #range:[#min:1,#max10]] ]
end

You can build a longer list of properties in the same manner or by adding individual properties to an empty property list like this...

addProp description, #movement, [#default:5,#format:#integer, ¬
                                 #comment:"Speed", #range:[#min:1,#max10]]

The last sentence in the first bullet should also be reworded as follows:

If building the property list directly, a colon separates the name's definition and the list of attributes. If using the addProp method, a comma separates the name's definition and the list of attributes.

Page 159: Left column, fourth paragraph

The first paragraph is incorrect. The scriptInstanceList can indeed be tested AND set. You can add new instances of behaviors to this list and modify it at will if you wish. Be sure you know what you are doing though... ;-)