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/
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 mails | Author | Date |
|---|---|---|
| Jonathan Dann | Mar 19, 12:37 | |
| Cathy Shive | Mar 19, 13:19 | |
| Jonathan Dann | Mar 20, 02:19 | |
| Cathy Shive | Mar 20, 08:40 | |
| Jonathan Dann | Mar 20, 12:35 | |
| Cathy Shive | Mar 20, 13:29 | |
| Paul Szego | Mar 20, 23:27 | |
| Jonathan Dann | Mar 21, 21:49 | |
| Cathy Shive | Mar 21, 22:31 | |
| Steve Weller | Mar 22, 04:25 | |
| Steve Weller | Mar 22, 04:31 | |
| Cathy Shive | Mar 22, 05:18 |






Cocoa mail archive

