Re: Correct use of NSViewController
Re: Correct use of NSViewController
- Subject: Re: Correct use of NSViewController
- From: Steve Weller <email@hidden>
- Date: Fri, 21 Mar 2008 20:25:31 -0700
I'm going down this same path I think. I have a split view with a
browser and a document. The way I solve it is to have the window
controller have outlets to the scroll views of the two panes of the
split view. Then in the window controller I do this:
- (void)windowDidLoad {
[super windowDidLoad];
// Create the browser view controller and give it its data source
browserViewController = [[BTPPBrowserViewController alloc]
initWithScrollView:browserScroller];
[browserViewController setDataSource:[[self document] imageStorage]];
[browserViewController windowDidLoad]; // Allow controller to set up
....
I split the initialization into two parts: the initialization of the
view controller where I provide the superview, and the the
windowDidLoad method where I let it finish setting up now it has its
data source (owned by the document). To tear it down I use:
// Window will close
-(void)windowWillClose:(NSNotification *)notification;
{
// Tell all the view controllers that the window will close
[browserViewController windowWillClose];
}
Of course I will add more view controllers as I create them.
My view controllers hide the view implementation from the higher
levels. My browser is an IKBrowwserView, so I have limited control
over it.
Of course I am still learning, so all of this may be fatally flawed....
On Mar 20, 2008, at 2:53 AM, Cathy Shive wrote:
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 (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
--
Blog: http://www.bagelturf.com/ Photos: http://bagelturf.smugmug.com/
_______________________________________________
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