Re: NSScrollView: special handling of subview's headerView?
Re: NSScrollView: special handling of subview's headerView?
- Subject: Re: NSScrollView: special handling of subview's headerView?
- From: Aaron Burghardt <email@hidden>
- Date: Wed, 24 Jun 2009 06:13:44 -0400
On Jun 24, 2009, at 12:28 AM, Quincey Morris wrote:
Also see:
http://codehackers.net/blog/?p=10
Ah, yes, that is precisely the same issue.
The behavior is partially described here:
http://developer.apple.com/documentation/Cocoa/Conceptual/TableView/Concepts/TableParts.html
although you'd be justified in concluding that it only happens with
an embedded NSTableView (or subclass like NSOutlineView).
You might want to file a bug against NSScrollView itself, instead of
the documentation. Having it check random classes for random method
names seems a bit rude. It should probably only check if the subview
is some kind of NSTableView, or whatever.
Once I determined that it was related to "headerView", I found that
page in the documentation, but, I agree, it can be interpreted to mean
that it only applies to an NSTableView. My problem was one of
discovery: I wasn't working with a table view or a subclass, and my
view wouldn't have revealed the behavior if I hadn't made it the
documentView of an NSScrollView. It took me a long while to determine
that it had anything to do with the name "headerView", so I was
searching for the wrong answer (such as "nsview subview automatically
removed").
If you expect the behavior, it's a small convenience, but I think you
are right that it would be safer and less confusing if the
NSScrollView only moved it when the view is an NSTableView or subclass.
Incidentally, the fact that this behavior found a instance variable
of yours implies that your NSView subclass lets
'accessInstanceVariablesDirectly:' return YES (the default).
Unfortunately there doesn't seem a way to make this default to NO (a
*much* better idea -- the dangers far outweigh any convenience,
since the default pretty much makes all your instance variables
public), but this is a useful lesson that overriding it to return NO
in every class you write is not a bad idea (though a PITA to do).
I misspoke–I had accessors for the variable, too. I just tested it
without the accessors and the headerView is not moved, so it must be
using with respondsToSelector:.
Thanks for the confirmation.
Aaron
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