Copyright 2004 by M. Uli Kusterer Fri, 29 Nov -1901 11:06:32 GMT Comments on article blog-nsopenglview-and-ib at Zathras.de http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm blog-nsopenglview-and-ib Comments witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) witness_dot_of_dot_teachtext_at_gmx_dot_net (M. Uli Kusterer) en-us Comment 5 by Ross Franklin http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm#comment5 http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm#comment5 Thank you so much. I was having the exact same problem, it was bugging me to no end. I had copy-pasted the code from the CocoaGL sample project, so I knew that it should be working, but I couldn't for the life of me figure out what was special in the sample project.

I now got it working, thanks to you. I also found another Apple tutorial that walks through setting up both views. This could still be made a bit more clear the by CocoaGL sample project.

developer.apple.com/documentation/graphicsimaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/chapter_3_section_3.html
Comment 4 by Jim Hillhouse http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm#comment4 http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm#comment4 Jim Hillhouse writes:
Uli,

Thank you for clarifying that NSOpenGLView is indeed NOT the view that uses, rather that a CustomView is. Yeah, big-time bug report. When one opens the LIbrary pallet in IB and sees under Views & Cells that ol' OpenGLView, it sure is easy to think that this is the one to use when drawing OpenGL in a window, even knowing that you must use your subclass of NSOpenGLView. So why does OpenGLView exist?

Jim
Comment 3 by ken http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm#comment3 http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm#comment3 ..as they should be. All designated initializers should always be overridden if a subclass needs any initialization of its own. (-copyWithZone: counts too, for classes that conform to NSCopying)
Comment 2 by dgohara http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm#comment2 http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm#comment2 dgohara writes:
I agree with Ken. I inadvertantly stumbled across the same thing a while back looking at the OpenGL examples. I couldn't figure it out until I recalled that Aaron Hillegass has an OpenGL example in his "Cocoa Programming for Mac OS X" book. After stepping through that, it became obvious that initWithCoder was being called instead of initWithFrame:pixelFormat:. But even that took a while to figure out since BOTH methods are implemented in his example.
Comment 1 by ken http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm#comment1 http://www.zathras.de/angelweb/blog-nsopenglview-and-ib.htm#comment1 Uli, did you try overriding -initWithCoder:? That's the init method that I expect to be called for all objects in a nib, excepting (1) 'Custom View' objects dragged from the palette, which receive initWithFrame:, and (2) custom subclasses of NSObject, which receive init.

This used to be explained in a document called "What Happens When a Nib File is Loaded", which was unfortunately replaced with something less accurate. I filed a bug for this.

Nevertheless, that doesn't sound like enough to completely remove your drawing, so something else is probably wrong too.