> --- Nicolas Roard <[EMAIL PROTECTED]> 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.> _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
