• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: Cocoa Open GL help
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Prev by Date: RE: *That* book
  • Next by Date: Re: *That* book
  • Previous by thread: Re: Cocoa Open GL help
  • Next by thread: Creating NSBitmapImageRep from NSImage
  • Index(es):
    • Date
    • Thread