Changes made to Ergo to support multiple boards:

(1) Delete ErgoApp.[hm], move all their code into BoardWindow.[hm] (see below).

(2) Make BoardWindow.[hm] identical to ErgoApp.[hm] except for removing the boardWindow instance variable (all references to it become self) and changing its place in the inheritance hierarchy (the "NXApp" code is now in a subclass of Window).  Add a new openNewBoard: action message.

(3) Make owner in Ergo.nib the Application class; "The Board" window becomes a BoardWindow and is made the delegate of the Application object (this allows the new "NXApp" (which is the BoardWindow) to receive the appDidInit: message).

(4) Make new nib module(s), e.g., Board.nib in the Other_Boards subdirectory, containing a MainWindow, which now must be of class BoardWindow.

(5) Change all instances of "[NXApp <ErgoApp Msg>]" to "[[self window] <ErgoApp Msg>]" (N.B. set/discardTrackingRects msgs already use [self window]).  This affects AbstractSquare, AbstractFilledSquare, and EmptySquare.  There's a small glitch in AbstractFilledSquare's mouseUp: -- a free that used to work fine now fails trying a [self window] after a [self removeFromSuperview].  The solution is to reorder a [setIsSelected: NO] so it properly resets the state that the free was supposed to clean up...one of those nasty cases where "things just aren't as simple as they seem."  Object re-use can be tricky.

(6) Add an awake message to AbstractSquare (as in the Palette version);  this allows boards in Other_Boards to be created using the ErgoPalette.palette.


In this example, I've gone to somewhat of an extreme to avoid using an ErgoApp object, just as an exercise.  Even the openNewBoard: message goes to a BoardWindow (this explains why there must always be at least one Board window active for this version of Ergo to work properly).  In a larger application, not having an XXXApp (or a global controller) object can be inconvenient.

									Charles