What if I want two (or more) windows to track each other's state?
Re-think your design.
If I follow you, you're basically thinking of something like Photoshop. You have one or more document windows, and additional panels that show the layers in the current document, the currently selected drawing tool options, the undo stack, etc.
The important concept here is that these windows are *not* tracking each other's state. They are not even aware of one another's existence. They are all tracking the state of the document - i.e. the model object in MVC terms.
For instance, I might want to navigate the window that's open to the "File/Access" tab, but have the window with the "File/Metadata" go automagically to the same place(s). What's the usual approach to "inter-object communication"?
The usual approach is to have a model object that's separate from the controller(s). Simple, single-window apps can get away with combining the two, but as you're finding out, that approach doesn't scale well beyond a single window per model.
So, you have a class - let's call it "FileInfo" - that represents your model data. It has various methods for accessing that data - getUserPermissions(), getMetadata(), and so forth. These methods do the obvious thing - they return the request information about the object's currently selected file. Your class will also need a setFile() method. As you'd expect, this method makes the requested file current. What's less obvious is that it also fires off an NSNotification that tells any interested observers that it has done so.
Window controllers are such interested observers, and when you open a new window, they register themselves as such. When they receive notification that the document displayed in their controlled window(s) has changed, they call that document's accessor methods to get the information they need to update the window.
Some windows - Photoshop's layers panel, for example - aren't tied to a particular document. Instead, they reflect information about the current document. The controllers for these windows, in addition to being notified of changes in the current document, also register to be notified when a new window becomes the main window, and the document it displays therefore becomes the current document.
So, to tie it together, what happens is this: In response to some event - a browser selection, the results of a "open file" panel, whatever - a window controller calls its associated document's setFile() method. It doesn't update itself visually at this point. The document object, after updating itself with the info about the selected file, tells any interested observers that it has done so. The observers - possibly, but not necessarily, including the controller that made the earlier call to setFile() - then update the contents of their windows by calling the changed document's accessor methods to get the information they need.
sherm--
