Re: Cocoa Open GL help
Re: Cocoa Open GL help
- Subject: Re: Cocoa Open GL help
- From: Vince DeMarco <email@hidden>
- Date: Wed, 12 Sep 2001 20:07:52 -0700
On Wednesday, September 12, 2001, at 04:55 pm, Brent Gulanowski wrote:
(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...
Yes this is exactly correct.
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.
By set some properties i mean set anything that appears in the Info Panel
in the Attributes inspector.
You have more configurability of a custom view, but anyways.
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 awakeFromNib is sent right after the nib file is loaded and all of the
objects in the nib file have been created and connected..
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?
What is giving you all the problems specifically, there are hooks to let
you know all aspects of the app startup.
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).
Yes drawRect: only gets call if the size of the view changes (gets
reshaped) or the dirty flag is set on the view (needs redisplay and needs
redisplay in rect).
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.
You could instanciate the model objects in the nib file to and then
connect them? why won't this work???
If you call init on an object that already exists? generally it will be
reinitialized, but i don't think you should do it that way.
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.
I think that performSelector:withObject:afterDelay: is also implemented
with Timers etc..
vince