The Compiler Knows

The TCL undo mechanism - How do you undo?

By John A. Love, III, MacTech Magazine Regular Contributing Author

About the author

John is a member of the Washington Apple Pi Users’ Group from the greater Washington D.C. metropolitan area and can be reached on America Online {John Love} and on GEnie {J.LOVE7}. Take note that John appears to be more rested for this article, although he apparently succumbs at the very end.

This series

The purpose of this continuing series is to laboriously trace through the source code of Symantec’s THINK Class Library (TCL) that serves as the Object Oriented Programming (OOP) arm of their Pascal and C compilers to provide the answers to the age-old question, “Who does what to whom?”.

Forrest Tanaka and Sandy Mossberg wake up, this one’s for you also!!!

This article ...

In the first of my “TCL Knick-Knacks” series (August 1992) I addressed what I considered the basics inherent to programming using the TCL:

• creation and initialization of an application object.

• creation and initialization of the all-purpose Event Loop.

• starting up your application.

• running and running and running and ... that Event Loop until you quit the application.

• creation of the document object(s) that the application object supervises.

• creation of the MENUs.

• implementation of MENU commands such as “Save” and “Copy”.

• handling of Desk Accessories.

Several months later (November 1992) I described how Tear-Off Menus are created primarily because I just out-and-out think they’re neat and also because I opened my big mouth and promised I would in the August article.

This month I think I should return to basics this time exploring how the TCL implements the notorious “Undo” Menu command. I might add that Neil is very thankful TCL’s implementation of “Undo” is relatively straightforward (translate “requires relatively few words to describe”). [Concise explanations - the dream of every editor. - Ed.]

A commercial break

You will notice that both the source code fragments as well as the surrounding explanation address QuickTime™ movies. The reason is very simple ... they’re directly extracted from my new CQuickTime, CMovie and CMovieEditTask classes which are included within my “CQuickTime.sea” package uploaded to both GEnie and America Online. So what are you waiting for?

And now we return to our regularly scheduled program(ming)

I will talk about the specifics of QuickTime™ only as they affect the task at hand, namely “Undoing”. But first some generalities

With only slight modification by yours truly, here’s what Symantec’s “Object-Oriented Programming Manual” states:

“The TCL uses the abstract class CTask (sub to CObject) to implement undoable actions. For every undoable action you want in your application, you need to create a subclass of CTask.

“After you perform an action, you create a new CTask and initialize it. Within your ITask method, you store enough information to undo it in your added CTask’s instance variables. Then you pass the newly created CTask to your supervisor (e.g., a CDocument) in a Notify message. CDocument:::Notify stores the passed CTask into CDocument::lastTask after it disposes of the previously stored lastTask. When you choose Undo from the Edit Menu, CDocument::DoCommand does the following:

/* 1 */

 void CDocument::DoCommand (long theCommand)
 {
 switch (theCommand)
 {
 // etc.
 
 case cmdUndo:
 if (lastTask != NULL)
 {
 if (undone)
 lastTask-> Redo();
 else
 lastTask-> Undo();

 undone = !undone;
 UpdateUndo();
 }
 break;
 
 default:
 inherited::DoCommand(theCommand);
 break;
 } /* end: switch */
 }

Well I guess my modifications are more than just slight let’s live with them anyway and explore the words in detail.

When TCL’s CDocument::IDocument is called, CDocument’s instance variable = lastTask is initialized to NULL. How does CDocument’s IDocument get called? Answer when any of the following occurs:

1) When the user double-clicks on one of your app’s documents to start up the application. CApplication::Run calls CApplication’s Preload which will then call CApplication::OpenDocument wherein IDocument should be called.

2) When the user double-clicks on the app itself for start up. Preload will not call OpenDocument in this case because numPreloads returned from _CountAppFiles = 0; however, Preload will continue with a call to CApplication’s StartUpAction which will then:

/* 2 */

 if (!gSystem.hasAppleEvents &&
  (numPreloads == 0))
 gGopher->DoCommand(cmdNew);

Since gGopher at this point is still our app (look at IApplication’s source), CApplication::CreateDocument is called. The latter is empty, so in your overridden version you should call IDocument.

What happens if System 7 is percolating and gSystem.hasAppleEvents is TRUE? Well after CApplication::Run calls Preload, the former calls CApplication’s Process1Event which then calls:

 itsSwitchboard->ProcessEvent();

to setup the all-knowing Event Loop. CSwitchboard’s ProcessEvent calls _WaitNextEvent which detects an AppleEvent with an event ID = kAEOpenApplication. As a result, CSwitchboard::DispatchEvent is called and the latter calls CSwitchboard’s DoHighLevelEvent. (The TCL assumes all high level Events are AppleEvents so you must override DoHighLevelEvent if you use high level Events that do not follow the AppleEvent Interprocess Messaging Protocol.) DoHighLevelEvent calls _AEProcessAppleEvent which calls any AppleEvent Handler you’ve installed.

Whoa, Nellie!!! I think I musta missed somin!!! Oh, yeah here’s the missing link way back when IApplication is called, CApplication’s MakeSwitchboard is called and the latter calls CSwitchboard::ISwitchboard. This dude calls _AEInstallEventHandler to install CSwitchboard’s “AppleEventHandler”. The latter calls:

 gApplication->itsSwitchboard-> DoAppleEvent( );

This little fella eventually calls:

 gGopher->DoAppleEvent(aAppleEvent);

Once again, gGopher = your app, so CApplication::DoAppleEvent is called to:

 gGopher->DoCommand(cmdNew);

if we double-clicked on just the app.

Double-clicking on a document would instigate an AppleEvent with an event ID = kAEOpenDocument with the result that DoAppleEvent eventually calls CApplication::OpenDocument( ). NOT!! Look at CApplication’s Preload after OpenDocument is called. The former continues with a call to _ClrAppFiles to instruct the Finder™ that this document has been processed. As a result, the call to _WaitNextEvent within CSwitchboard::ProcessEvent will not detect an AppleEvent - it’s “done gone” !!!

Hey, is this TCL great or what

but plenty of time for a nap later!

In my TCL implementation of QuickTime™, a QuickTime™ movie document is a CQuickTime object, a sub-class to CDocument. Furthermore, my CMovie class is sub to CPane. When I either create a new movie document or open an existing disk-stored movie document, the first thing I call is INewQuickTime or IQuickTime, respectively. In either case, inherited::IDocument is called to initialize lastTask to NULL as I’ve already stipulated. In both cases also, I then create a new CMovie object and initialize it. This CMovie or CPane object is the sole pane or sub-view of the movie window and has two component parts, translate “instance variables”. The latter are a movie and a movie controller.

This CPane is then stuffed into CQuickTime’s itsMainPane, an instance variable inherited from CDocument and into a specially added CQuickTime instance variable that I name itsMovie. When I call IMovie to initialize my new CMovie object, I call inherited::IPane( ) which eventually calls IPaneX( ) to add my CMovie pane as a sub-view of my movie window. I also call BecomeGopher(TRUE) which method my CPane = CMovie inherits from CBureaucrat. BecomeGopher makes gGopher = my CMovie. After I return from IMovie to either INewQuickTime or IQuickTime, I then set CQuickTime::itsGopher, inherited from CDirector, = my just-initialized CMovie.

One of the key points of all this is that the gopher is a CPane rather than a CDocument as it is under more conventional circumstances. My rationale for this exception is based strictly on the answer to “What exactly am I undoing?”. I wish to undo all the usual editing commands such as Cut and Copy. I am cutting or copying movie frame(s) that constitute one of the two components of a CMovie pane, not a movie document which is a CQuickTime object = CDocument. As a matter of fact, I can have a CQuickTime document consisting of the solitary CMovie window pane whose movie component is empty (guess what my INewQuickTime does? - there’ll be a quiz tomorrow morning).

So when CSwitchboard detects a mouseDown Event and calls CDesktop’s DispatchClick, the latter may find that said mouseDown occurred in the Menubar. As a result:

 gGopher->DoCommand( );

is called which is really my CMovie::DoCommand. So what does the latter look like? Before I get into any more QuickTime™ details, the real question is “What must it look like in order to implement undoing?”, QuickTime™ or not..

Another Commercial break

Just to complete the description of my OOP implementation of QuickTime™, a QuickTime™ movie file is a CResFile object, said file dutifully stored in CQuickTime::itsFile as inherited from CDocument. Although itsFile is a CFile, CResFile is sub to CFile, so everything’s right with the world. CFile objects come into play with saving-to-disk, which subject I am not going to cover this month. Reverting changes to the CQuickTime document by temporary, un-saved editing commands is another subject not to be covered here. However, curiosity will hopefully get the better of you kind readers and you will download my “CQuickTime.sea” file from either GEnie or America Online.

On with the Main Feature

What must my CMovie::DoCommand look like in order to implement undoing?

/* 3 */

void  CMovie::DoCommand (long theCommand)
{
 CMovieEditTask  *newEditTask = NULL;

 // whatever  

 switch (theCommand)
 {
 case cmdCut:
 
 TRY
 {
 newEditTask = new (CMovieEditTask);
 newEditTask-> IMovieEditTask(this, theCommand, 
 cFirstMovieEditTaskIndex);

The purpose of your overridden version of CTask::ITask is to simply store whatever variables in your added CTask’s instance variables are required in order to support undoing, for example, what your movie looks like before the Cut operation.

/* 4 */

 }
 CATCH
 {
 ForgetObject(newEditTask);
 }
 ENDTRY;
 
 lastMovieEditTask = newEditTask;

“lastMovieEditTask” is an added instance variable of type = CMovieEditTask (sub to CTask) in my CMovie class. Remember that I’m cutting, copying etc. movie frame(s) from my CMovie pane so said CMovieEditTask rightfully belongs to the CMovie object, not to the CQuickTime object which is a document. In short, I’m editing a pane, not the pane’s supervisor. Granted I save the latter, but that’s about all.

/* 5 */

 // cut something.
 
 Notify(lastMovieEditTask);

Notify is not a method of a CPane, so it propagates up to CBureaucrat::Notify which calls:

 itsSupervisor->Notify(...);

The supervisor of my CMovie pane is my CQuickTime document. So CDocument::Notify gets called and the latter sets CDocument::lastTask = the passed CMovieEditTask after it disposes of the previous lastTask if there’s one. Although CDocument’s Notify method expects a passed CTask, CMovieEditTask is sub to CTask so everything’s cool. Remember, IDocument sets lastTask = NULL. Notify also sets CDocument’s undone to FALSE and dirty to TRUE.

 lastMovieEditTask->Do();

The purpose of your overridden version of CTask::Do is to store whatever variables in your added CTask’s instance variables are required in order to support undoing; for example, what your movie looks like after the Cut operation.

/* 6 */

 /* Whatever floats your boat
 ** to finish it off!!!     */
 
 break; /* cmdCut */

 case cmdCopy:

 // somethin or another

 break;

 // etc.

 default:
 inherited::DoCommand(theCommand);

 } /* end: switch */

)/* end: DoCommand */

Before we progress any further, let’s pickup some loose ends.

Some QuickTime™ Classes

Now, let’s look at some of my QuickTime™ classes that implement “Undo”:

First, the CDocument

/* 7 */
class CQuickTime : public CDocument  {

public:

   /*
   ** = CDocument::itsFile:
   ** CMovieFile *itsMovieFile;   
   */
 CMovie *itsMovie;
 Movie  savedMovie;


      voidIQuickTime (CApplication *itsSupervisor);
 void   INewQuickTime (CApplication *itsSupervisor);
 virtualvoidDisplayQuickTime (void);
 virtualvoidDispose (void);

 // etc.

}; /* CQuickTime */

The itsMovie instance variable contains the CMovie window pane that is newly created and initialized within both IQuickTime and INewQuickTime. This data is required when I close a movie window, which disposes of my CQuickTime document. Remember when I previously stated that my CMovie pane class contains two instance variables = a movie and a movie controller? Well, when I dispose of the CQuickTime document, I need access to the stored CMovie because I must first call _DisposeMovie and _DisposeMovieController before I call the inherited CDocument::Dispose().

The savedMovie instance variable is used for reverting the CQuickTime document to the last saved version. OhOh I remember saying I wasn’t going to talk about reverting this month so forget I said anything!!!

Then, the CPane

/* 8 */
class CMovie : public CPane {

public:

 Movie    moov;
 MovieController   mc;
  // = CDocument::lastTask:
 CMovieEditTask  *lastMovieEditTask;
 static short  
         cFirstMovieEditTaskIndex;
 
 
 void   IMovie (CView *anEnclosure, 
 CBureaucrat *aSupervisor);
 
 virtualvoidNewMovie (void);
 virtualvoidOpenMovie (SFReply *macSFReply);

 // etc.

}; /* CMovie */

I’ve already addressed the first three instance variables. The fourth one comes into focus when I discuss IMovieEditTask later on.

The IMovie method initializes my CPane as I’ve already said. NewMovie creates an empty movie by calling _NewMovie and a movie controller by calling _NewMovieController. My OpenMovie method is called after you select a disk-stored movie file with the special movie version of the _SFGetFile dialog, namely, _SFGetFilePreview. OpenMovie extracts the QuickTime™ movie from the movie file via a call to _NewMovieFromFile and extracts the associated movie controller via calls to _FindNextComponent and _OpenComponent. To enable editing, OpenMovie continues by passing the functional result from _OpenComponent, = a QuickTime™ movie controller, to _MCEnableEditing.

Finally, the CTask

/* 9 */

class CMovieEditTask : public CTask  {

protected:

 Movie  originalMoov, newMoov,
 originalScrap, newScrap;

It turns out that _MCUndo interchanges the old and the new movie selections, so we don’t need to retain this info. Cool it for now because I’ll expand on this later:

/* 10 */

  /*
 TimeValueoriginalTime,
 originalDuration;
  */
 CMovie *editedMoviePane;
 long   editCmd;

public:
 
 void   IMovieEditTask (CMovie *thisMoviePane, 
 long theCommand, short firstTaskIndex);
 virtualvoidDo (void);
 virtualvoidUndo (void);
/*
 Just calls Undo:
 virtualvoidRedo (void);
*/
 virtualvoidDispose (void);
 
}; /* CMovieEditTask */

As a matter of general review, when IDocument is called by my IQuickTime or INewQuickTime, CDocument’s lastTask is set to NULL. You have also learned that my CMovieEditTask object is passed to Notify for subsequent storage into CDocument::lastTask. You are about to learn one of the reasons why. Look at the source for CDocument::Notify to see that prior to saving this current task in lastTask:

 lastTask->Dispose();

is called to dispose of the previous lastTask after ensuring that this previous lastTask is not NULL.

The closing of a window is much more convoluted, but the same result ensues. You click in the window’s goAway box and you enter CDesktop’s DispatchClick which accesses CWindow’s Close method. Subsequently, you eventually enter CDirector::CloseWind which takes you to CDirector’s Close. You journey returns you to CDocument’s Dispose wherein the TCL calls ForgetObject(lastTask). Look up this routine in Symantec’s file = “TCLUtilities.c”. You will immediately see that ForgetObject calls lastTask ->Dispose. Wallah!!!

Way, way back I talked about saving some info in your overridden CTask so you can implement undoing. The saved info is represented above by the instance variables.

The first two represent the QuickTime™ movie before and after you paste previously cut or copied movie frames, for example. You’ll see in a little bit that these first two movies are needed only when reverting or pasting. For the remaining editing operations a simple call to _MCUndo handles it all, so for these latter operations I simply set these buzzards to NULL.

I’ve got to quantify these “Moov” movies as NULL because for reverting and pasting these Moovs are new movies and, therefore, must be disposed of by CMovieEditTask’s Dispose() method before the latter calls the Dispose() method inherited from the superclass = CTask. I call _DisposeMovie only when “originalMoov” and “newMoov” are not NULL.

The next two movies represent the contents of the public Scrap, once again, before and after your editing operation. These Scrap movies are needed only when cutting or copying simply because reverting, pasting and clearing obviously do not affect the Scrap. For these latter operations, I set the Scrap VARs to NULL with the result that the contents of the Scrap are left intact. The other result is as before, namely, _DisposeMovie is not called for “originalScrap” and “newScrap” within my task’s Dispose() method. When cutting or copying, however, these Scrap movies are new movies and must be disposed of.

The variables labeled “original” are recorded by IMovieEditTask and the variables labeled “new” are recorded by the task’s Do method.

As stated above, I’ll address later the two TimeValue VARs. IMovieEditTask stores the passed thisMoviePane into our instance variable = editedMoviePane. This saving operation is mandatory because both Do and Undo need access to the QuickTime™ movie and movie controller neatly tucked away inside my CMovie object.

Undo what, man !!!

The editCmd instance variable is also needed by Do and Undo since each editing operation requires potentially unique reactions. In effect, we implement:

/* 11 */

 switch (editCmd)
 {
 case cmd1:
 // ...
 break;
 
 // etc.
 }

“Undo Copy Movie” and “Undo Clear Movie” are just some examples of what should appear as text in the Edit Menu’s first menu item. How does the TCL make this happen? “The Compiler just knows, that’s all!!!” Stay tuned for a more precise answer:

The TCL “Starter.Π.rsrc” file inclued with Symantec’s Pascal and C compilers has a ‘STR#’ resource with a name = “Task Names” and an ID = 130. This resource looks like:

/* 12 */

#define STRtaskNames 130

resource‘STR#’ (STRtaskNames, “Task Names”, purgeable)   {

 {
 /* [ 1] */
 “Typing”,
 /* [ 2] */
 “Cut”,
 /* [ 3] */
 “Copy”,
 /* [ 4] */
 “Paste”,
 /* [ 5] */
 “Clear”
 /* [ 6] */
 “Formatting”
 };

};

Before I get into what this sucker does for a living, let’s change said STR# resource 
as follows:

/* 13 */

resource‘STR#’ (STRtaskNames, “Task Names”, purgeable)   {

 {
 /* [ 1] */
 “Revert to Saved Movie”,
 /* [ 2] */
 “Cut Movie”,
 /* [ 3] */
 “Copy Movie”,
 /* [ 4] */
 “Paste Movie”,
 /* [ 5] */
 “Clear Movie”
 };

};

You shoulda gotten the hint by now the what of Undo what is described in the STR components of this STR# resource. Go back to my August 1992 article and review how CDocument::UpdateMenus() is called when you click on the Menubar. Then go to the source code of the latter and see:

/* 14 */

 if (lastTask != NULL)
 {
 gBartender->EnableCmd(cmdUndo);
 UpdateUndo();
 }

The focus for this discussion is CDocument’s UpdateUndo:

/* 15 */

void  CDocument::UpdateUndo()
{
 Str255 status;
 Str255 task;
 
 if (active){
 GetIndString(status, STRcommon, 
 (undone) ? strREDO : strUNDO);
 GetIndString(task, STRtaskNames, 
 lastTask->GetNameIndex());
 ConcatPStrings(status, task);
 
 } else {
 GetIndString(status, STRcommon, strUNDO);
 }
 
 gBartender->SetCmdText(cmdUndo, status);
}

STRcommon, as defined in TCL’s “Constants.h” file, equals 128. This ‘STR#’ resource, as it exist’s in Symantec’s “Starter.Π.rsrc” contains seven(7) component ‘STR ‘s. We perform a cut operation and CDocument’s Notify method is called to set CDocument::undone = FALSE. As a direct result, the local status Str255 contains “Undo”. The second call to _GetIndString accesses our own ‘STR#’ resource whose ID = 130. I have not explained CTask’s GetNameIndex method yet; however, for the moment just pretend that it returns a value = 2. Pressing on, the two local Str255s are concatenated with the result that the first item in the Edit Menu reads “Undo Cut Movie”. Once again is this TCL great or what!!!

Go back a few(?) pages and look at the code snippet extracted from CDocument::DoCommand. You pull down the Edit Menu and you select “Undo Cut Movie”. CDocument::undone is still FALSE so you go to:

 lastTask->Undo();

Since lastTask is really a CMovieEditTask, you’ll end up at my CMovieEditTask::Undo(). You (un)do your thing and then switch CDocument::undo back to TRUE; after all, the cut is now undone, right? Finally, you end by returning to the method UpdateUndo which dutifully changes the Menu item’s text to “Redo Cut Movie”. See I told you the TCL is great stuff.

One last straggler

What about CTask’s GetNameIndex? Way, way back I said that before any editing operation I call my IMovieEditTask. Well the tail end of this contraption looks like:

/* 16 */

void  CMovieEditTask::IMovieEditTask (CMovie *thisMoviePane,
 long theCommand, short firstTaskIndex)
{

 // record “originalMoov”,
 // “originalScrap” and
 // other sordid matters.

 if (firstTaskIndex > 0)
 {
 if (theCommand == cmdRevert)
 taskIndex = firstTaskIndex;
 else
 taskIndex = firstTaskIndex + theCommand - cmdCut + 1;
 }
 else taskIndex = 0;

 inherited::ITask(taskIndex);
}

In my CMovie::DoCommand code snippet presented above for the Command = cmdCut, the very first thing I accomplished was to create a new newEditTask of type = CMovieEditTask. Then:

/* 17 */

 newEditTask->IMovieEditTask(this, cmdCut, 
 cFirstMovieEditTask);

Since this message is being sent within a CMovie method, the passed this is my CMovie pane. Next, it looks like theCommand = cmdCut. Now the really interesting part. The last passed parm is the class variable = cFirstMovieEditTask (review Symantec’s naming conventions in their “Object-Oriented Programming Manual”).

What the

After you folks download my “CQuickTime.sea” package, take a gander at my file = “CmyApp.c” wherein:

 short CMovie:: cFirstMovieEditTaskIndex = 1;

which initializes CMovie’s class variable, the fourth instance variable of CMovie I avoided discussing earlier.

Just for a moment, however, let’s pretend that I initialized it to 0. As a result, IMovieEditTask above passes 0 to CTask::ITask which stores the passed 0 to CTask::nameIndex.

The elusive GetNameIndex method of CTask simply:

 return (nameIndex);

which in this case is 0. Look up _GetIndString within the now-old “Inside Macintosh, Volume I” to discover that since the index is not >= 1, _GetIndString returns an empty string. Since “Undo” + “” = “Undo”, the Menu item text remains the same.

Back to reality I initialize cFirstMovieEditTaskIndex to 1 and pass this sucker to my IMovieEditTask. Before I go any further, carefully observe the order of the STR components that constitute my STR# resource, ID = 130. That same order must be repeated in your MENU resource. This is very critical because

within my IMovieEditTask the passed index directly correlates with the passed Command number. If we were reverting, the index passed to CTask::ITask is 1 so CDocument’s UpdateUndo retrieves the first string in my STR# resource and the Edit Menu’s first item will read “Undo Revert to Saved Movie”.

If we were cutting QuickTime™ movie frame(s), then:

 taskIndex = 1 + cmdCut - cmdCut +1;

which obviously equals 2. The fundamental reason for this lopsided arithmetic centers on the disabled dotted line in your Edit Menu between “Undo” and “Cut”.

A real humdinger

Here are some modified extracts from my “Read Me 1st” Microsoft WORD™ (Version 5) document that constitutes just one of the many components of my “CQuickTime.sea” file I’ve uploaded to both America Online and GEnie. By the way, this file is contained within America Online’s file = “QuickTime Movie Editor” and is placed within their “New files and free uploads” section. The uploaded file retains my name on GEnie and can be found by searching for my name directly:

Try out the Movie item(s) under the “File” Menu of “Feature Flick” if you do not have the “QuickTime” INIT in your System Folder <translate “in your Extensions Folder” for those with System 7>, you will get a spiffy Dialog telling you what a silly you are !!!

If you do have “QuickTime”, make certain that you have the special version of the “Scrapbook” DA that can be used to store “QuickTime” Movies. The usual items under my Edit Menu help you do just that. Speaking of editing ... you can cut, copy and clear single frames, that is, the one you’re viewingat any given time. If you wish to cut, copy or clear the entire daggum Movie, simply press the <Shift> key while you’re pulling down the Edit Menu or using the CMD-key equivalents, e.g., <CMD-Shift> X. Notice the wording change of the Edit Menu items as you press and release the <Shift> key. For pasting, with the <Shift> key released, you will always paste or insert after the frame you’re staring at; if the <Shift> key is pressed, you will paste over or replace the whole Movie. QuickTime allows you to select several contiguous frames by pressing the <Shift> key as you use the Controller Bar to progress from one frame to its neighbor. Note that these frames must be contiguous for this “Shift-Click” method to work. Also, try my added feature wherein you can use the Arrow keys on your keyboard to go from one frame to another.

In addition, the “Edit” Menu has an item called “Show Clipboard”, which name toggles between “Show Clipboard” and “Hide Clipboard” depending on whether the Clipboard window is currently hidden or visible, respectively. In QuickTime parlance, that which shows after copying or cutting a Movie frame(s) is called a Movie “Poster”, a PICTure representation of that which was copied or cut. If just one frame was copied or cut, then just that frame shows. If multiple frames were copied or cut, then the first frame in that multiple frame sequence is presented.

Check out the “Movie” Menu that incorporates several of the capabilities available through use of the Controller Bar. For example, if you find the above-mentioned <Shift-Click> method cumbersome in order to select contiguous frames, try the “Select Frames ...” item under the “Movie” Menu. I’ve also incorporated a VCR Remote-like floating window to further assist you. My OOP code for the latter is implemented using TCL’s class = CIconPane and is based on the pioneering procedural source code of Edgar Lee from Macintosh Developer Tech Support at Apple, Inc.

Additionally, I’ve taken the liberty of including several files in my “Bonus” folder. One is a Microsoft WORD™ document that shows an alphabetized table of absolutely every instance variable, Class-wide, for TCL Version 1.1.2. I really feel that such a listing is invaluable to the beginning or advanced TCL programmer who cannot remember to which Class a particular instance variable belongs. Granted ... the index in back of Symantec’s TCL Manual addresses all the instance methods, but not the instance variables. I deliberately chose to present this listing in table-form so that you could re-arrange in any order you wish; for example, you may wish to alphabetize first by Class and then alphabetize the instance variables within each Class ... your choice. If you do implement an ordering scheme different from mine, be sure to adjust accordingly the pseudo-headings I’ve placed at the top of each page. These pseudo-headings are actually table entries; to keep it simple, just remove them before you re-order.

The remaining two files in my “Bonus” folder pertain to Bill Steinberg’s “System Error Table” DA. One is a resource file that you copy over to Bill’s DA using your favorite Resource Editor. The second is another WORD™ doc, this one a rendition of Bill’s error list. All I’ve done is supplement Bill’s info with QuickTime data.

OhOh !!!

Before finishing this article I noticed that there are a few(?) points I have not covered I know I promised but there’s always the next article!!!