Jonathan,
I just wanted to say one more thing. I was re-reading what you had
written and I see the problem you're having with setting up the frame
for that first split view.
The problem isn't just the set up of your view controllers and the
order of creating/adding views, you're also dealing with the issue of
setting an auto-resizing mask for your view. Wouldn't it be great if
your view controller for the split view could just configure the view
to "fill" it's size to match the size of it's superview instead of
having to explicitly size and position it when it's created? This is
a flaw in this system. The sub view controller has to be able to
access the view of its super controller so that it can inspect its
frame. With the way autoresizing currently works in NSView, you're
never going to get around this.
So the part of my system that I haven't described, because I just
realized that it is important to this issue, is that I have coded my
own resizing behavior into my NSView subclass to add these kinds of
features. I have a "FillWidthAndHeight" option, for instance (I use
this one most often). This way I don't have to know the super view's
frame when I add a subview. At the end of the original window
controller's init method, I just reset the frame of the window, and
NSView goes through the view hierarchy and they all size themselves
correctly within their superviews. In fact, when I create my views,
many of them are initialized with an NSZeroRect and the first thing
my window controller does is set the content view of the window to be
one of my NSView subclasses. This topic is much more difficult to
tackle, but if you want a truly dynamic view system, your view code
needs to be able to work without any prior knowledge about the super
view's and sibling view's frames.
IMHO, this is the the Pandora's Box when it comes to working with the
view hierarchy. The standard autoresizing mechanism isn't really
built to handle dynamic layout changes. You always have to know the
exact size of your view and its position within its superview (and
sometimes the size and position of sibling views) before you set it.
If you need to program a complex, dynamic view system where sizing
and positioning managed in the code, first subclass NSView and figure
out a way to deal with autoresizing. Maybe this is a bigger project
than you have time take on right now and maybe its unnecessary for
the scope of your project, but you're going to bang your head against
this issue over and over again as you develop more dynamic layouts.
It's important to keep in mind the fact that NSView's autoresizing
and NSWindowController were created to support interfaces that get
laid out in IB and don't change much after their awake from nib state.
I really hope that I haven't made the issue more complicated for you!
Cathy
On Mar 20, 2008, at 2:19 AM, Jonathan Dann wrote:
Hi Cathy,
Thanks for the comprehensive answer to my question, I wanted to
make sure that I wasn't committing heresy by going down the 'tree
of view controllers' road before jumping in and refactoring all my
code. I was hoping to set it up so I could forget about most of
the memory management as I'm replacing views all over the place at
runtime.
Out of interest, when I add my main split view, I then have to set
its size to fit my document window's content view. As this task is
view-related it seems like it the split view's NSViewController
should handle the size calculation and placing of the view in the
correct place in the window. I allocate and instantiate my view
controller in my NSWindowController subclass, then set the split
view as a subview of the content view and then in the -
awakeFromNib of the view controller I get the split view's
superview's (the content view's) frame, doing my resiing from there.
Would you do the same, as this seems to encapsulate the logic
properly, or would you just set it all in the window controller?
Thanks again, you've been really helpful.
Jonathan
_______________________________________________
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 [EMAIL PROTECTED]
