Access through the keyboard

The cunning plan

In the previous section, we missed out a vital step: that of getting the parent script into the scriptText area of the currently playing document.

Objects are created from parent scripts located in the scriptText of the Director cast members (see figures 1.10 to 1.14).

If a suitable parent script can be embedded into the text of the "Input" field, we can instruct the player engine to put it into the scriptText of a cast member slot where we know the engine will find it later when we instruct the cell to create an object.

Using this cunning plan, we can fill the RAM space of the biotelemorphic cell with all kinds of interacting and cooperating objects.

Objects in Director

The object oriented features of the Lingo scripting language allow us to designate areas in memory to be used for self contained objects which can act like applications (similar to the way Java applets can be used in a browser environment). The media and the methods used by these objects, run under the core Lingo code (engine) of the biotelemorphic cell.

Potentially, these objects can be arranged to do anything any multimedia document can do and can be designed to be powerful applications in their own right. We shall be covering the design of objects extensively later in the book but for the purpose of these opening chapters we shall use skeleton objects with just token abilities and characteristics.

To demonstrate how objects can be created and established using the simple "Portal" document, we will create a simple object named "objectCreator" in the RAM space allocated to the biotelemorphic cell we have just used.

We will do this in easy stages, for those who might not be familiar with Director; explaining, as we go, how objects are created and used in the Director environment.

Director makes it easy to create objects in RAM because all you have to do is issue a birthing statement and the object is created from the parent script and the address of that object returned as a result of the birthing statement.

In affect, the programmer says "I want to create an object called FRED" from such and such parent script and then the Lingo engine checks what space is available, creates the object and immediately returns the address in RAM to which messages to FRED should be sent.

Once the FRED object is allocated an address, messages can be sent to FRED to correspond with the scripts in FRED's design. This allows FRED to be quite independent of anything else in the cell or the system.

The birthing statement is of the form:

set FRED to new(script "Fred's parent script")

From the moment that command line is issued, FRED is in existence as an object in RAM. The variable FRED will have received an allocated address in memory so that any instructions or data sent to the variable FRED will automatically go to the address in memory contained in the variable FRED.

Note:

If this is your first exposure to objects and all this seems like Mickey Mouse, don't worry, there are plenty of examples coming up which will thoroughly familiarize you with object creation, design and use.

At this stage, it is only important to know that an object can be created by means of a text which is placed into a named area of memory which the Lingo engine of the biotelemorphic cell can find. The object is represented by a variable (usually a permanent global) to which messages should be directed.

Now, the cunning plan with "Director made" biotelemorphic cells, requires that we slip a parent script for an object into the portal document and position it into the scriptText area of the cell's records.

To do this, we shall need to arrange a suitable "stepping stone" within the portal document. This we can do by using a "dummy" cast member.

In Director, with the authoring package, we create a field member from the menu and give it the name "dummy". This member will be automatically created with a scriptText which we set to do "nothing" (see figure 1.16).

Having created this "dummy" member, we have a named cast member whose scriptText we can use to pass on parent scripts to the code engine of the biotelemorphic cell.

Figure 1.16

Previously prepared dummy text cast member with dummy script put into the "Portal" movie

Type into the "Input" field of the "portal" document (making sure there is a space between the "--" commenting out word and the next word):

-- on new me

-- return me

-- end

--

-- on makeANoise me

-- beep 3

-- end

set fieldName to "dummy"

set the scriptText of member fieldName to embeddedScript

global objectCreator

set objectCreator to new(script fieldName)

When the "Do" button is used to do this field, the mouseUp handler parses the commented out new and makeANoise handlers: putting them into a variable called embeddedScript.

The do command then proceeds to execute each line in the field in turn, except for those lines which were commented out (i.e., those starting with the word "--")

Note:

Notice that these script lines in the "Input" field begin by placing the field (member) name into a variable. This is because the do command isn't happy with quotation marks and should be avoided at all times except when used in the context of placing strings into variables.

The executable command lines of the script in the "Input" field cause the "Do" button to place the contents of the variable embeddedScript into the scriptText of the previously prepared dummy text field named "Dummy".

Note:

Simply by setting up the scriptText of a cast member in a Director movie with a birth handler, turns any scriptText into a possible parent script for creating objects in RAM.

After clicking on the "Do" button", the scriptText of the "dummy" will appear as shown in figure 1.17.

Figure 1.17

The scriptText of the "Dummy" cast member turned into a parent script after pressing the "Do" button

As mentioned previously, to be able to communicate with objects easily, they are usually "birthed" into variables. This allows messages to be sent to a name rather than to an obscure RAM address, i.e., the variable bearing the name of the object is not the object itself but a container which holds the address of the object - where any messages addressed to the named variable are passed.

In this case, an object is birthed from the parent script of the "Dummy" cast member by the lines:

global objectCreator

set objectCreator to new(script fieldName)

With the "Do" button, these final two lines in the "input" field create a global called objectCreator and then births an object into this global using the newly installed parent script of the cast member "dummy". This newly created object can then be addressed by the name objectCreator.

To prove that you have created an object with the same abilities as the parent script that was placed in "Dummy": click on the "do" button, clear the "Input" field with a drag selection and a delete.

Type into the empty "Input" field, the command lines:

global objectCreator

makeANoise objectCreator

Now click on the "Do" button again. You should hear three beeps. This is the makeANoise object in RAM carrying out the instructions in the handler makeANoise

If you want to know exactly what this objectCreator object is, clear the "Input field again and type:

put return & objectCreator after field fieldName

Then click the "Do" button.

You'll find something like that shown in figure 1.18, where the content of the global variable objectCreator is shown as containing an address in memory. This is the address of the object to which all messages addressed to the variable objectCreator will be sent.

Figure 1.18

The content of the global variable "objectCreator" is shown to contain the object's address in memory (RAM space of the cell)

The full scope of this cunning trick lies in the fact that once an object is created in RAM by the cell engine it no longer needs its parent script. This leaves the scriptText of the "dummy" cast member free to be used to bring another parent script in - to be able to create another kind of object on RAM.

Any number of different kinds of objects can thus be created in RAM using this same entry route into the biotelemorphic cell.

You might reflect upon the fact that this is analogous to the kind of strategy which viruses use to invade and take control of biological cells. It is also similar to the kind of strategy which is used in genetic engineering and molecular biology to modify or change cell structure or function.

Hopefully, this section will have given you some sort of an idea as to what an object is and how you can get them into the RAM space allotted to a biotelemorphic cell.

Details of book, CD-ROM and online continuation - peter@genps.demon.co.uk