Re: makeWindowControllers
Re: makeWindowControllers
- Subject: Re: makeWindowControllers
- From: Brent Gulanowski <email@hidden>
- Date: Wed, 2 Jul 2003 18:23:14 -0400
On Wednesday, July 2, 2003, at 05:36 PM, mmalcolm crawford wrote:
On Wednesday, July 2, 2003, at 12:36 PM, Brent Gulanowski wrote:
Docs don't say that overrides of -makeWindowControllers are supposed
to call super's version, but if I don't, -windowControllerDidLoadNib
does not get called. How non-intuitive is that?
-windowControllerDidLoadNib gets called by the window controller, not
the document! What's going on in NSDocument's default implementation
of makeWindowControllers that I'm forgetting in my version? There is
nothing apparently wrong with calling super's implementation, but in
testing, I notice that it's trying to call -windowNibName. The docs
make it sound like my version is replacing NSDocument's version, not
augmenting it.
Since you're using multiple window controllers, it makes sense for
each window controller to look after its own window -- that's what
it's there for :-)
In your custom NSWindowController subclasses, override windowDidLoad,
and put the controller logic there. In your case, for
SCMainWindowController, perhaps:
-(void) windowDidLoad {
[[self document] createTextures];
}
(This is a cleaner implementation, avoiding the need to check for the
WC's class...)
Mmalcolm and Carl,
I see what you're saying, but I had -createTextures as a private
method, to signify that it was not supposed to be called at any time
other than when the document is created. If I expose it, what is a good
way to make it clear that the method is not for general use? In the
interests of maintainability.
I'd prefer to create the textures earlier, except that the view and its
OpenGLContext must exist first (or crashola), and that won't happen
until after the Nib is loaded.
For now, I'm just invoking -createTextures from -makeWindowControllers
(after calling [mainWindowController window] to force nib loading). I
don't like it, so a better solution that is cleaning and more in
keeping with the document architecture would be desired. There are
simply some places where OpenGL and Cocoa don't mesh seamlessly, so far.
More specifically, the model has to keep control of the textures,
despite their importance to the view, because it has to use the vertex
co-ordinates and texture name to draw itself. OpenGL by its nature
makes it difficult, sometimes impossible, to properly de-couple model
from what is ideally view, without duplicating a ton of state
information and having to constantly synchronize them. Essentially I
have to find the least offensive solution.
Brent Gulanowski
--
Mac game development news and discussion
http://www.idevgames.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.