Re: Problem with NSTabView

[Nicola Pero]

> --- Nicolas Roard <nro@witbe.net> wrote:
> >
> > I have now a little anoying problem; when I resize the NSSplitView, the view
> > in
> > the current tab is correctly informed of the size changement, but not the
> > other tabs.
> 
> Here is a small patch that fixes this. However, I'm not sure if this is
> correct. I set the view's frame to the contentRect of the tabView which makes
> this look better, but should it rather only draw the original view that falls
> within the bounds of the visible area (i.e. no new frame size)?

Thanks - the concept of the patch is correct, and I applied it.

The concept of the patch is correct, because it makes sense that the
NSTabView calls setFrame: on each view when it displays the view, to tell
the view what the frame is.  It's up to the view to decide what to do of
that frame!

The view can override setFrame: to implement custom behaviours if it
wishes to do so :-)

Anyway - when you use it in practice, what happens - I expect you to use a
normal (NSView *) as the view associated to your NSTabViewItem, and then
put into this view all your objects in various places.  Your objects
(buttons, textfields, whatever) are subviews of this view.

When the NSTabView calls setFrame: of the view, the view will resize
itself which involves calling -resizeSubviewsWithOldSize: on itself; this
method will call -resizeWithOldSuperviewSize: on all views inside it
(which normally are your objects).

Each of your objects can use the autoresizing masks and/or custom
resizeWithOldSuperviewSize: implementations to resize itself appropriately
and to place itself appropriately inside the view, reacting to the change
in size (all standard gui objects contain complete code to do that).

This is what I expect to be a normal usage of it (if you use it from Gorm,
I expect it to create a NSView by default as view associated with each new
NSTabViewItem.  You can then drag your gui objects and put them inside
this view, and you get precisely into the situation I described).

If you want to do anything more perverse and evil, it's pretty simple -
you override setFrame: in the view associated with your tab view item.

Normally you wouldn't use a premade gui object as the view, but who knows,
_if_ you know what you are doing, it might be the right thing to do.  
Using the top-level 'controlling' NSView and putting actual objects inside
it is what I expect to be more appropriate and safer in most situations -
so it is what I'd suggest to programmers to do.  It won't hurt and it is
definitely what you normally want.

<so if anyone contributes a nice new demo/example of the NSTabView, which
would be very nice, please write it in this way, using an
intermediate/controller NSView.>