Re: Cocoa Open GL help
Re: Cocoa Open GL help
- Subject: Re: Cocoa Open GL help
- From: Brent Gulanowski <email@hidden>
- Date: Wed, 12 Sep 2001 19:55:04 -0400
(see below...)
>
From: Vince DeMarco <email@hidden>
>
On Wednesday, September 12, 2001, at 09:26 am, Carlos Weber wrote:
>
>
>
>
> On Wednesday, September 12, 2001, at 05:53 , Vince DeMarco wrote:
>
>
>
>> If you use a CustomView and set the class to MyOpenGLView then
>
>> initWithFrame: will get called but if MyOpenGLView is set as a custom
>
>> class to the NSOpenGLView that you drag in from the palette, the
>
>> initWithFrame: method on MyOpenGLView will never get called.
>
>>
>
>> Am i just confusing everyone or is this explanation helping????
>
>
I understand what you're saying, but not the rationale...yet.
>
> I think the confusion is between the above two different methods (in IB)
>
> of getting an NSOpenGLView (or custom subclass thereof) into your view or
>
> window: starting with dragging a CustomView widget (initWithFrame: is
>
> called) versus starting with the NSOpenGLView widget (initWithFrame:
>
> never called if you have subclassed). There are example projects out
>
> there employing both methods, and until this distinction registered with
>
> me it was difficult for me to figure out why things were being done so
>
> differently in the different examples.
>
>
>
>
The only reason to do the CustomClass version is that you want to set some
>
properties of the widget in IB, and not do it via code as you would have
>
to with the other method.
>
>
vince
If I understand correctly:
Dragging an NSOpenGLView widget and subclassing it to myOpenGLView means
_no_ -init method gets called (because IB figures it knows what an
NSOpenGLView needs and sets it up first?) <-- this is the way I was doing it
then...
Dragging a CustomView widget and subclassing it to myOpenGLView (subclass of
NSOpenGLView) means that -initWithFrame: gets called. <-- this is totally
not intuitive; the reverse of these states is what I'd have expected...
What is it to "set some properties" of the widget in IB? Anything that
appears in the Info Palette? But if asked without knowing, one would expect
_more_ configurability of a not custom view... then again, what's irksome
here is that, whatever widget dragged, the class of the view is _still_ a
subclass of NSOpenGLView! So the behaviour being different at all is weird
to me, but undoubtedly experience will help.
In any case, this solves my problem of not being able to call OpenGL
functions from -awakeFromNib. I'll check the docs on that method to see if I
can figure out how OpenGL can be unready at that point; I suppose it happens
right after the classes are loaded? The startup sequence for a Cocoa app is
still very obscure to me. So much is hidden. For all the irritation of
setting up managers manually in Classic, at least I know what was going to
work. Does Learning Cocoa detail the app starting up process?
I suppose if I didn't have -initWithFrame: to do things like set the view
aspect and clear the background etc I could appoint a delegate to the
application object and use that to call a once-only -resetView method in
myOpenGLView. Then I wouldn't have to do an
if(viewChanged) [self resetView]
at the beginning of -drawRect:
In fact, if -drawRect: only gets called when the view is reshaped or
uncovered, then I obviously should do resetting there anyway. My _real_
problem was that I disagree with the sample code examples which do the
actual scene drawing in -drawRect: ; I want to do it in my model or at least
controller objects, since I need to be able to change the content in the
view for different cameras (eventually).
So now that I understand that -init's aren't always being called for NIB
objects, I can stop instantiating member objects in them, and use the
delegate's -applicationDidFinishLoading to trigger my own initialization
methods for views and controllers when I can be sure everything is safe and
working. My big problem up to now was that I was instantiating model objects
in -init methods that weren't being called, and when I was expecting
drawing, I was getting a nice white square (nothing around to draw
anything), and SIGBUS errors when I tried to talk to said instances. What
happens if I call -init on an object already in existence? I suppose it
would have side-effects down the road, unless I use a flag to ignore
redundant calls.
BTW, I'm using a self-calling function to do my background (drawing) tasks,
by calling
[self performSelector: _cmd withObject: nil afterDelay: (elapsedTaskTime -
idealWaitTime)]
which seems to be working wonderfully, but I noticed that the Teapot
application uses NSTimers added to the RunLoop. I guess that the latter is
more civilized, but is there any danger with the former? It's another place
where I can use a flag to stop it, but all of these boolean flags seem...
clumsy for Cocoa apps. I like the idea that messaging should do all the
if-else work for me. Guess that doesn't apply within an implementation tho.
brent