Programming for Interactive Multimedia
Notes from Week Four

Objects & Object Oriented Programming revisited

Properties of objects

Objects are

self-contained -- think of them as little black boxes with an in and out point that only let information in and spit information out. They don't care where the information came from or where it's going. They hide what they do (a term called "information hiding"), because in being totally self-centered they can be much more efficient. They only care about their own variables (with an exception) and their own properties. They take data in, do what appears to all outside to be "magic" and spit data out.

reusable -- we want objects to be as generic as possible: vehicle vs. car, moving character vs. bad guy/good guy (or even bad guy 1/ bad guy 2, bad guy 3). There is a GREAT Director example: the cast -- members include bitmap vector sound text button video script field shockwave 3D all different media yet all CAST members have a member number, a name (or should!), a type and the property that they are the building blocks for the score and stage. Each cast member can then have further properties based on its type, but the most generic thing is that it is still a cast member.

This idea of reuse goes for the scripts that we write for our built-in objects as well as any objects we create. When we write Lingo, we don't want to hardcode--we want to build in flexibility to everything.

A frame number can change if you add, delete or move frames (or can become irrelevant if you move some sprites) so to be generic we use markers instead of frame numbers for reference.
A cast member's number will changes if it is moved in the Cast (like if we sort the cast) so we use cast member names, not numbers, for reference.
The channel number of a sprite can change if we rearrange the sprites in the score, so we use properties such as "the clickOn" (if you need to get the channel number from a mouse Click), or "spriteNum" (if you need to get the spriteNumber from any other event), to "ask" the sprite itself for it's number.

I say above "when we write Lingo" because Director is a sophisticated enough program to be able to update the frame numbers and channel numbers and cast member numbers for anything on the stage and score that it controls. For example, if you flip-flop the sprites in channel 2 (which uses cast member 5) and channel 4 (cast member 6), it will know that sprite channel 2 now contains member number 6 and sprite channel 4 now contains cast member 5. But if you wrote a script in Lingo that was looking for cast member 5 in channel 2 (and you had switched them in the score), your script would not run, or would do something you had not intended.

made up of data and procedures --in Lingo we refer to the data as "properties" and refer to the procedures and "behaviors" or "handlers" or "scripts"

To begin with we will use the built in objects of Director -- cast member, sprite, frame, stage, window, movie. Later, in the section on Parent/Child scripting, we'll learn how to build our own "objects." But we WILL focus on reuse of code from the beginning.

Objects communicate with each other via messages. The message can contain the existence of a particular event and any information that that object would need to work it's magic. For example, if the object, say a cast member, has a nice, reusable function in it called moveMeH (for move me horizontally) that needs to know the direction (left or right, (- or +) and amount (number of pixels), and the sprite number that needs moving :

The message going in says moveMeH(-3,2)

The function inside says

on moveMeH(somewhere, something)

sprite(something).locH = sprite(something).locH + somewhere

end moveMeH

(Looking ahead: in case you want to know, this functions "needs" (somewhere, something) are called "arguments" and the information pieces sent in (-3,2) are called "parameters". MORE ON ALL OF THIS LATER! )

That saves us from having to hardcode exact sprite numbers and movement amounts, so we can use that object for a bunch of things

Events and hierarchies

Definition and types of events

An event is something that occurs during the playback of a movie (i.e. when your user is using the movie or you are testing it). There are four (4) types of events in Lingo:

user feedback events (all mouse and keyboard interactions)
playback events (start & stopMovie, begin & endSprite, enter and exitFrame)
time events (idle & timeOut)
window events (activate move resize zoom and closeWindow)

We would think events happen all of the time, but, as far as Director is concerned, events only "happen" if there is a handler (like on mouseUp or on enterFrame) to "capture" and respond to that event somewhere in a script (movie, cast, sprite, frame).

Event hierarchy (and script scope)

When an event is triggered, Director searches through a hierarchy of scripts to find a handler associated with that event. Many different handlers may respond to that same event, but the script at the top of the hierarchy has the final say in what happens.

Think of one of those change sorting machines that sorts out quarters and dimes and nickels and pennies. If the first layer catches quarters, then no quarters go to the next layer. If the next layer catches quarters and dimes, it doesn't matter for the quarters--there are no quarters to catch--so it catches the dimes. The next layer can catch dimes and pennies. Again, there will be no dimes, but it will catch the pennies. Only the nickels will be left to pass through.

Here's an example more akin to our movie metaphor:

In the play, Jeannie, the always wears red

In scene 3, at a funeral, Jeanie wears black. So Jeannie's "scene script" overrides Jeannie's "movie script" as far as her costuming in concerned.

This is akin to the hierarchy of scripts in Lingo. A primary event handler receives the event first. Primary event handlers are on mouseDown, on mouseUp, on rightMouseDown, on keyDown, on keyUp and on timeout. By default, these pass the messages onto other scripts rather than "consuming" them. If multiple scripts have handlers for the same event, only the script at the top of the hierarchy will be executed-- the others will be skipped.

The hierarchy of the scripts, from highest to lowest, is:

sprite
cast
frame
movie

The scope of each type of script is the opposite of its hierarchy:

movie--the entire movie

frame--affects any sprite (incl. cast member) that is active in that frame
cast--affects every instance of that cast member in the score
sprite--affects only one sprite only for the duration of that sprite. Scripts are attached to the sprite, not the channel, so even if another sprite occurs at a different time in that channel, that sprite is only affected by its own sprite script

So if you want a script to affect the most elements/objects in Director, you'd go the global route and put it in a movie script. If you want to make sure that a particular event is handled differently that scripted somewhere else, you'd go for the top of the event hierarchy and make it a sprite script.

References

Class handout on built-in Director events, Chapter 8 of Director 8 Demystified.

Programming for Interactive Mulitmedia I Home