It’s all Just Ones and Zeros

By now, you’ve become used to the idea that files, stored on a computer, are really little more than collections of data or instructions of some kind that either tell the computer how to behave (as with system files) or tell the program that opened the file how to behave (as with your own Director movies when you’re running them in Director itself). And the files themselves exist on disk as nothing but binary information, which is a collection of ones and zeros, laid down magnetically on the hard drive.

Fortunately for us, computers understand how to write out those ones and zeros so that they create document files that make sense, such as a letter to someone, an image file, and so on?documents that, when opened using a program that can understand how to interpret their contents, become humanly comprehensible items of information.

You saw in Module 2 that it’s possible to get Director to access an HTML file from the Internet, and that your Director movie understood the file well enough to display it onscreen. You might be interested to know that HTML files are nothing more than plain text, with some formatting instructions embedded in them. This implies that Director can read and understand text files that have been created in other programs entirely?and that’s exactly the case, as it turns out.

Just as HTML is text with some hidden formatting instructions, there’s a file type that most word processors can create, called Rich Text Format (RTF), that behaves a lot like HTML. It, too, contains hidden formatting instructions, but RTF files are meant mostly for use in desktop publishing applications, not for general use on the Internet. As it happens, RTF is another file type that Director can read and understand, just as it does with HTML.

There’s a third kind of text file that Director handles with ease, and that is the plain-vanilla American Standard Code for Information Interchange (ASCII) text file. These files are generally not formatted with any special font instructions; they’re raw data, containing nothing but straightforward text characters, spaces, and so on. Some e-mail programs use ASCII-formatted text to transmit information. Programs such as Notepad or SimpleText write ASCII text files.

Tip: In Windows, ASCII text filenames generally end with a .txt extension. You can easily confirm all the above by importing some HTML, RTF, and ASCII files into Director, but that’s not all that interesting compared to giving the end user the ability to do exactly the same.

File not Found

You’ve worked with programs and documents enough now to realize that it’s not sufficient for a program to simply try to automatically load some random file every time it’s run. After all, different people configure their computers differently, place their files in different folders on the drive, and give their files different names. How would any program know which file to try to load when it runs? Such a scheme would be doomed.

This is why programs have a File | Open command. Selecting File | Open in a program opens a dialog box asking you to locate the file you want to open. Once you’ve done so, the program proceeds, and your file is opened, usually in a document window, ready for you to peruse, edit, save, rename, and so on. Director is no exception; if you’re working on a movie and want to open another, you can do so with File | Open…just as you can with any other program.

I’m sure you can think of situations in which you’d want to have that ability in your own Director movies, running as projectors, and since I’ve alluded to FileIO previously, perhaps you’re guessing that ability exists. You’re guessing correctly.

FileIO is an Xtra provided with Director by Macromedia. Originally, it was used to write plain-text (ASCII) files to disk and to read those files off of disk, in the days before Director was capable of importing or saving such files on its own. Over the years, Director’s abilities in these areas have expanded, but you still need FileIO to get information, such as where the file is located or where the user wants a file saved, and there are still plenty of times when FileIO is the best way to go about saving any manner of external data.

The chief purpose of FileIO is to permit you to program Director to locate any desired file, open it, read its contents, save any changes made to the file, and close it again. FileIO is also designed to allow you to create new documents on-the-fly, documents that never existed before you constructed them.

Note: The IO in FileIO is short for input and output, which is what FileIO does. It allows you to perform file input and output operations from and to the hard drive. If you’re looking through your Lingo manuals for information on FileIO, don’t bother. This particular Xtra has never been especially well documented by Macromedia, in spite of the fact that it’s one of the more important Xtras available. In fact, the documentation for FileIO is nowhere to be found except online. I’ve added a link to the page you need in the online resource site for this text at www.nightwares.com/director_beginners_guide/ in the section named "FileIO." You won’t need the full text of that document to proceed here; just know that it’s available to you when the time comes for you to go looking for it.

Opening a Dialog Box

There are two basic steps to working with FileIO:

  1. Open a dialog box that asks the user to locate a file to open or choose a place to save a file.
  2. Read information from or write information to that file once the user has told you where it is.
So, logically, we’ll start with the dialog box you use in FileIO to open files.

Begin, as always, with a new Director file. You can use the same Stage size you used for the racquetball and breakout games, if you want. Place a button on the Stage someplace and label it Open file… Then, create a new behavior in the PI for that sprite. Into the behavior, type the following code:
 

on mouseUp me
 
 
oFileObject = new ( xtra "fileio" )
oFileObject.displayOpen()
END mouseUp


You probably don’t recognize anything in either of these lines, but you can infer their meaning. In the first line, oFileObject = new ( xtra "fileio" ), we’re creating an instance of the FileIO Xtra, using the new keyword, and putting that instance into a variable called oFileObject. The letter o at the beginning of this variable’s name indicates that we are in fact using a code object in this script. We’ll be making extensive use of objects in Part IV; this is a sort of preview.

The second line, oFileObject.displayOpen(), sends a command, displayOpen(), to the code object instance we have in the oFileObject variable. To demonstrate what the displayOpen()command does, click the Play button in your movie, and then click the Open file… button you just programmed. Once you’ve seen it in action, click the Cancel button; there’s no real point in doing anything else just yet.

As you’ve just seen, the premanufactured commands in the FileIO Xtra permit you to create a system-standard Open File dialog box. This is just like any other Open File dialog box you see on your computer, and all of its controls behave in exactly the same fashion. What’s more, the dialog box you get on a Mac will be a Mac-style box, and the one you get on Windows will be a Windows-style one. In other words, you’re presenting users with the controls they have already seen and know how to use. With two lines of code!