Skip navigation.
 
mlRe: Correct use of NSViewController
FROM : Steve Weller
DATE : Sat Mar 22 04:25:31 2008

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_removed>)
>
> 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/<email_removed>
>
> This email sent to <email_removed>


--
Blog:    Photos: <A href="http://bagelturf.smugmug.com/">http://bagelturf.smugmug.com/

Related mailsAuthorDate
mlCorrect use of NSViewController Jonathan Dann Mar 19, 12:37
mlRe: Correct use of NSViewController Cathy Shive Mar 19, 13:19
mlRe: Correct use of NSViewController Jonathan Dann Mar 20, 02:19
mlRe: Correct use of NSViewController Cathy Shive Mar 20, 08:40
mlRe: Correct use of NSViewController Jonathan Dann Mar 20, 12:35
mlRe: Correct use of NSViewController Cathy Shive Mar 20, 13:29
mlRe: Correct use of NSViewController Paul Szego Mar 20, 23:27
mlRe: Correct use of NSViewController Jonathan Dann Mar 21, 21:49
mlRe: Correct use of NSViewController Cathy Shive Mar 21, 22:31
mlRe: Correct use of NSViewController Steve Weller Mar 22, 04:25
mlRe: Correct use of NSViewController Steve Weller Mar 22, 04:31
mlRe: Correct use of NSViewController Cathy Shive Mar 22, 05:18