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: Quincey Morris <email@hidden>
- Date: Tue, 23 Jun 2009 21:28:11 -0700
On Jun 23, 2009, at 18:11, Aaron Burghardt wrote:
I recently encountered a problem with a custom NSView sublcass that
is designed to be a container for 3 WebViews and is embedded in a
scroll view. The problem was that once the view was added to the
view hierarchy, one of its WebViews was removed and inserted as a
sibling to the view. I posted a question on the WebKit SDK mailing
list because I thought my problem was related to WebView, but I
determined that it occurred because my NSView subclass had an
instance variable named headerView and that view was automatically
set up as if a header, similar to an NSTableView or NSOutlineView
column headerView. Renaming the ivar eliminated the problem. My
question is, is this documented behavior? I intend to file a
documentation bug, but I wanted to make sure I didn't miss something.
Also see:
http://codehackers.net/blog/?p=10
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.
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).
_______________________________________________
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