Re: Windows and views and controls, oh my!
Re: Windows and views and controls, oh my!
- Subject: Re: Windows and views and controls, oh my!
- From: Quincey Morris <email@hidden>
- Date: Mon, 05 Sep 2011 21:42:21 -0700
On Sep 5, 2011, at 20:43 , N!K wrote:
> The examples I've seen all show a window with a view in it and how to draw in that view. But I want to put up a window with a couple of views in it and draw in them individually, sometimes clearing and redrawing, sometimes adding more drawing.
You're misusing the term "view" and I have to conclude that you've mis-absorbed what a view is.
A view is not so much a construct for breaking apart the visual *appearance* of a window as a construct for organizing the *process* of drawing window contents. That is, views are mostly about apportioning responsibility, and not so much about providing a canvas (although, in the end, they are that too).
In Cocoa, you really don't "draw in" views. Rather, views draw themselves. That's the first conceptual hurdle you need to overcome.
The second hurdle is that in Cocoa the view appearance is conceptually redrawn from scratch as necessary. That is, having drawn something, a view doesn't just assume its previous appearance is persistent and can be erased. Instead, the window appearance is achieved by layering the drawing done by each view in a controlled manner, and this happens every time the window contents needs to be drawn or redrawn.
Now, a view certainly *can* cache its own previous visual state (as a bitmap, or via some other intermediate representation), but that sort of thing is generally done only if necessary for performance reasons, because it's a lot more coding work.
Thus, if you have a custom view that draws one or more graphs superimposed, where there is a user option to control which graphs are shown, you don't add a second graph simply by drawing it on top of something that already exists from a previous drawing pass. Instead, you "add" it by redrawing the entire view, but with 2 graphs instead of 1 (except, of course, in the exceptional case already mentioned case of manually caching previous drawing).
You say you want to put up a window "with a couple of views in it", but we have no idea what this means. You want to draw a couple of graphs, or something like that? Well, then, your task is about implementing a custom view that draws itself with some kind of custom appearance. That has, typically, very little to do with the mechanics of the window as a whole.
> (Controller code that takes input from pushbuttons and data entry are not a problem.)
FWIW, keep in mind that buttons and text fields are views, too.
> Do I need an NSWindow Controller at all?
Nothing in your considerations of views has anything do with the question of whether there's a window controller or not.
Others may disagree, but I believe that there's basically no reason ever *not* to use a window controller. Its prime function is to load and manage the nib resource file of its associated window, so using a window controller relieves you of the responsibility of writing that management code yourself. Window controllers are also useful as controller objects in the MVC sense (that is, as places to put certain business logic that links the window contents to the data model) and as window delegates (that is, as places to put certain code that customizes some of the window behavior).
> Ditto NSViewController?
No, view controllers are, paradigmatically, analogous to window controllers except that they manage loadable view resource files rather than window resource files. Unless you are swapping various different views in and out of a window a different times, you most likely will put your view resources in the window nib file, which means they get loaded with the window, and don't need to be separately managed.
It is certainly possible to use view controllers in more subtle ways (such as dividing controller responsibility when there is a lot of controller code). However, for fundamental purposes, you should simply consider that every window nib file should be paired with its own window controller (set as the nib's File's Owner object), and every view nib file should be paired with its own view controller (set ditto).
> I tried separate drawRect's in controllers but couldn't make them work.
The 'drawRect:' method belongs in a (custom) view, not in window or view controllers. It is the mechanism via which the view is told to draw itself -- it's something you implement but don't call yourself.
At this point you should probably stop trying to understand the Cocoa drawing architecture by examining sample code, and read some essential Apple documents. Start with the NSView Class Reference document, and read everything listed there as a "companion guide". Same thing starting from the NSWindow Class Reference.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden