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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
