In designing projects and presentations, you are probably used to the idea of opening up an application which has a full range of menus and helpful palettes to assist in the authoring process. With the help of the useful tools provided, you gradually build up your production and then, when it is finished, you attach the player, or engine of code, to run or play the production according to the designs specified in the authoring environment.
It may come as somewhat of a surprise then, to find in this book, we are going to learn how to dispense with an authoring environment altogether.
Instead of working from inside of an authoring application, we are going to work with just the player, the biotelemorphic cell. We are going to be on the outside of this cell, trying to get stuff in - something much like pushing components through the neck of a bottle to build a "ship in the bottle".
Concept note
It may cross your mind that this a convoluted way to go about creating Web and multimedia presentations: why not just create a proper multimedia document from one of the many multimedia authoring packages and then get the appropriate document player to play it?
A little thought will soon tell you that this would restrict access to the cell's engine code only to the people who possessed a full authoring package. It's not that we are worried about restricting the design of cell activity to the possessors of an authoring package; it's more that we don't want to restrict the design of cell activity to HUMANS.
This chapter is designed to bring out this point: we shall be arranging the cell to be controlled by documents.
Typing code into a field is a human way to do things and, even for a human, it isn't a very convenient way to program a cell, particularly if we want to do this from a remote computer located on the other side of the world across the Internet.
Ideally, we should like to arrange for the cell to get its input in the form of text documents, perhaps an email. This would also open up the programming of the cell to non humans - in fact, to any software application which could produce text - including the biotelemorphic cell itself (YES! the cell can become self programming and able to modify its own instructions - but more of that later in the book)
Figure 2.1 shows, diagrammatically, what we are looking for. We want the biotelemorphic cell to be able to accept inputs through a portal which passes them on to the engine code to create objects in RAM.
Figure 2.1
A Director 5 biotelemorphic cell illustrating the principle of inputs resulting in the creation of objects within the cell RAM space
Let's begin by making a working example of the design shown in figure 1.3 of chapter 1. This is the second paradigm, where the cell is modified to allow a human user to choose a particular document which contains instructions for the cell to act upon. This will involve redesigning the portal.
Using Director 5, we will construct a new portal document (remember we have to use the full Director authoring package to make portals) and this time add a facility to allow the cell to read in a text document (rather than a multimedia document created with an authoring package).
We will design this facility such that the text is placed into the "Input" field for the "Do" button to act upon:
Figure 2.2
A button script which imports a named text document and places it into a field named "Input"
Figure 2.2 shows a typical Director 5 Lingo button script which will import the text from a text document (named "Instruct.txt") and place it into a field named "Input".
Technical detail:
This script uses the FileIO Xtra which is built into the Director engine of the biotelemorphic cell. The line:
put FileIO(mNew,"read",theFile) into gReadObject
turns the variable gReadObject into an object (in RAM) which can be called upon to read text from the document named in the variable theText.
This gReadObject object is set to read the text one line at a time, in a repeat loop using the line:
put gReadObject(mreadLine) into it
Each line is then added to the variable theText until an empty line is encountered. When this happens the text reading object (gReadObject) is removed from RAM with the line:
gReadObject(mDispose)
and the text that has been placed into the variable theText is placed into the field "Input".
This simple script has two problems for our purposes. Firstly, it will stop whenever it encounters an empty line. Secondly it will read in all text encountered.
To make this text reading procedure more suitable for our purposes, it would be preferable if the text were parsed in some way so that only chosen sections of a document would be read and entered into the input field. This we can do with the script modified as shown in figure 2.3. The lines not darkened out are the lines added to the previous script.
Figure 2.3
Altering the "read" script so that it reads only a specified section
Figure 2.3 shows how each line read with the gReadObject is examined to see what word it starts with. It will ignore all lines until it encounters the special word "qxz", whereupon it will collect together all subsequent lines and put them into the "input" field, until it encounters the word again.
This simple parsing trick allows programming instructions to be included in any document - perhaps included in an ordinary email where any protocol headings , messages for humans or "chatty" stuff is ignored by the cell which reads only the part intended for the cell itself.
Looking forward a moment, to what we shall be doing later, it is quite easy to see how, using a number of different "parsing words" we could have many different messages embedded in a single text document. If you want a good metaphor - this is exactly how the DNA in our cells are used to activate the various embedded genes - but more of that later.
Note: the FileIO object gReadObject can be instructed to read only the text between certain specified characters of a text file, but, for the purposes of this book, we shall be parsing text using words rather than characters.
The next problem we encounter with the scripts shown in figures 2.2 and 2.3 is that they are "hard-wired" to read only one particular text document: "Instruct.txt".
What we want to be able to do is to arrange for the human chooser to be able to decide from a number of different options as to which text document (set of instructions} the cell reads from.
The fileIO object can be given an instruction to let the user choose any document available on the system with the command line:
set gReadObject to FileIO(mNew,"?read","txt")
This line, with the "?" before the parameter "read", will get the cell's code engine to bring up a standard system dialog box to allow the user to choose which document the cell reads from.
Unfortunately, as with the use of authoring packages to specify a cell's activity, this method necessitates having a human in the system - which might not always be convenient.
To overcome this problem, we can arrange for the cell to reference a specific directory or folder on the hard disk of the local system where it can look for or pick up its instructions.
If we look at a Director Lingo syntax book, we will find that the Director 5 cell's engine code will respond to a command:
getNthFileNameInFolder(theFolder,i)
This is a function call which will return the name of the file or document number i in a folder specified in the variable theFolder.
By using this function call in a repeat loop, we can get the name of every file or document contained in a particular directory or folder. Figure 2.4 shows a button script of a button included in the portal movie which gets the name of every file or document in a folder on the hard disk named "Instruct.fld".
Figure 2.4
Button script which gets the name of all the documents in a folder on the hard disk and puts them into a field
You will notice that the script in figure 2.4 puts all the names of the text files into a new field called "Instructions". For convenience, we arrange this new field to appear on a new screen (figure 2.5).
Figure 2.5
Frame 2 of portal showing the text files which are contained in the folder "Instruct.fld"
Technical note:
Director can arrange for different screen layouts by specifying different frames. For our purposes, all of these frames will be "paused" in the exitFrame handler. The portal we are designing here will have another frame added which will cause the screen to look like that shown in figure 2.5. Clicking on the button described in figure 2.4 will put all the file names into the field "Instructions" and then sets the screen to frame 2 where this "Instructions" field is displayed.
Once the file names are recorded in a field they will be accessible to all scripts and will be able to be used by non humans to retrieve the documents named.
To allow a human user to determine the cell's activity from a choice of these different instructions we can use the Lingo code in the cell's engine which tells us which line in a field is clicked on: the mouseLine.
Figure 2.6 shows a "click on" script (mouseUp and mouseDown) which we can put into the scriptText of the "Instruction" field.
Note: The engine of a Director biotelemorphic cell detects clicks on fields as well as buttons so it will activate any appropriate scripts in the scriptText area of the field when a mouse click is detected.
Figure 2.6
A field "click on" script which selects a document to be used for a cell's input instructions
When the clicked on line is detected, the script in the field tells the cell engine to select the file named in the line clicked on and to parse it between the markers (qxz) and place the parsed section into the input field.
Technical detail:
The field script of figure 2.6 is activated by any mouseUp message which is sent if the user clicks anywhere in the field. The handler that responds to this message uses the mouseLine() function in the cell's engine to return the number of the line the user clicked on. This line is highlighted on screen and the content of the line put into a variable fName.
The variable fName is then sent as a parameter with the message putItInInput to the handler of the same name written into the same scriptText as the mouseUp handler.
The putItInInput handler uses the fileIO XObject, similar to the way shown in figure 2.2, to read the file specified in the parameter. The part of the file between the two instances of the word "qxz" are parsed out and put into the "Input" field".
This device now allows the human user to select a text document to be placed into the "Input" field. All the user has to do then is to click on the "do" button and whatever instructions are contained in the selected text document will be sent to the code in the cell.
As we shall see later, even with this simple cell, people will be able to receive all kinds of complex programming instructions in their email messages.
Summary of the conceptual position this far
From a technical programming point of view, we haven't done anything spectacular. We've just used a few of the Lingo code instructions, incorporated in the engine of a biotelemorphic cell, to facilitate the transfer a piece of text from the hard disk to a field.
However, from a conceptual view point this is a major break through: we have provided a communication link between the cell and the outside world. More importantly this link can be used by both humans and text documents to control the activity of the biotelemorphic cell.
To illustrate, just how significant is this conceptual jump, let's send ourselves a few Emails. When they arrive we'll put them into the "Instruct.fld" folder and see how they perform.
copyright 1997 Peter Small - No part of this document can be used or reproduced in any form without express permission
Details of book, CD-ROM and online continuation - peter@genps.demon.co.uk