Re: Dynamically loading a part of a Window in Cocoa
Re: Dynamically loading a part of a Window in Cocoa
- Subject: Re: Dynamically loading a part of a Window in Cocoa
- From: "Adam R. Maxwell" <email@hidden>
- Date: Wed, 01 Jul 2009 18:50:56 -0700
On Jul 1, 2009, at 10:26 AM, Quincey Morris wrote:
On Jul 1, 2009, at 08:54, Adam R. Maxwell wrote:
I'm curious as to why people recommend a tabless NSTabView for
this. I've always found tabview subviews to be a pain to set up in
IB; the alignment and sizing seem really fiddly to get right.
Maybe I've been doing something wrong.
I agree with you about the IB side of setting it up, although it
*really* depends on the particular situation.
I've mostly tried with a tabview as a subview of a splitview, and I've
found that once it's set up, I don't dare move it.
Using multiple nibs instead of building one really complicated nib
has some distinct benefits for maintenance, in my experience.
But drawbacks, too:
-- When you add a subview, you have to write code to resize it to
fit the window real estate it's supposed to occupy. That's not hard,
but it's a line or two of glue code you don't have to write with tab
views.
-- You can't hook up IBOutlets directly from the window controller
to the view controller's objects in IB. Sometimes you can eliminate
the need for the outlet or move it to the view controller. If not,
it's not terribly hard to code around, but that's a few more lines
of glue code.
Good point; not being able to connect outlets can be a hassle. I
typically end up making weak references from the view controller to a
document object or similar controller, and that can get messy.
-- If you modularize your controllers, then bindings from the view
controller's objects get a bit harder. Either you have to defeat the
modularization by binding to File's Owner.windowController.whatever
(File's Owner being the view controller subclass, of course, and
windowController being a property you added to it), or you have to
"proxy" the bound properties in the view controller, which means
more glue code to forward the relevant accessors *and* KVO
notifications.
Well, I generally avoid bindings, since I can't comment nib/xib files,
and it takes too long to reverse engineer my own (or worse, someone
else's) bindings when I'm doing maintenance work. With that
perspective, the minor glue code to swap views is no big deal :).
Lastly, view controllers are Leopard only, so tab views win in Tiger-
compatible apps. :)
I've used NSWindowControllers and custom objects for this for years,
so that's also no big deal :). If the OP has a fixed set of views,
tabview could well be the easiest way to go, depending on the
complexity of the overall view hierarchy.
regards,
Adam
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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