Re: NSTableView and background color
Re: NSTableView and background color
- Subject: Re: NSTableView and background color
- From: jeff ganyard <email@hidden>
- Date: Wed, 22 Feb 2006 10:50:18 -0800
On Feb 22, 2006, at 10:02 AM, Corbin Dunn wrote:
hi jeff,
After reading a recent response from Corbin regarding table views
with non-selectable rows (feb 20), where he suggests returning nil
for the highlight color, I tried setting the background color of a
tableview to nil. I wanted to try and draw the tableview over
something irregular.
When I set the background color to nil the row highlight behavior
gets wonky, yes official term: wonky. Try it, you'll see what I
mean. :) Basically once a row is highlighted it remains highlight
regardless of change in selection. At first it look like the
tableview was allowing multiple selections (which is not turned on
in IB) but it appears to just be more of an display update problem.
How do I fix this? I do still want a highlight on the rows but
when the selection changes I want previous highlights to disappear.
On a related note, if I set the tableviews background color to
something with alpha < 1, the region under the table does not
display what should be under the table in the parent view (i.e.
the window background) instead it clips the region under the table
showing whatever is below the containing window. (does that make
sense?)
Trying to restate more clearly, set the tableview background to a
color with an alpha of 0 and you see right thru the table view and
thru the window that contains it. It's an interesting effect but
not desired. I would expect that you would see through the
tableview and just see the background of the containing view or
window.
It sounds like you need to override isOpaque in a tableview
subclass and return NO. TableView returns "YES" by default.
--corbin
isOpaque
- (BOOL)isOpaque
Overridden by subclasses to return YES if the receiver is opaque,
NO otherwise. A view object is opaque if it completely covers its
frame rectangle when drawing itself. NSView, being an abstract
class, performs no drawing at all and so returns NO.
See Also: – opaqueAncestor, – displayRectIgnoringOpacity:, –
displayIfNeededIgnoringOpacity, –
displayIfNeededInRectIgnoringOpacity:
Interesting concept of being able to have something that defines
itself as opaque display itself translucently. :)
Is your expectation that this will affect both issues? I can see how
it would affect the clipping issue but not sure how it would relate
to highlight drawing.
jeff _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden