RE: Cocoa Open GL help
RE: Cocoa Open GL help
- Subject: RE: Cocoa Open GL help
- From: Daniel Parnell <email@hidden>
- Date: Thu, 13 Sep 2001 11:00:39 +1000
G'day,
The way I do this is to create a window, put an OpenGL view onto the form
and then set the custom class for the OpenGL view to my OpenGL view. Then
everything seems to work quite nicely :)
I spent ages trying to figure out why my OpenGL stuff wasn't working.
Daniel
>
-----Original Message-----
>
From: Brent Gulanowski [mailto:email@hidden]
>
Sent: Thursday, 13 September 2001 9:55 AM
>
To: Cocoa Dev List
>
Subject: Re: Cocoa Open GL help
>
>
>
(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
>
_______________________________________________
>
cocoa-dev mailing list
>
email@hidden
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev