On Feb 26, 2008, at 10:21 PM, Seth Willits wrote:
On Feb 26, 2008, at 3:13 PM, John Stiles wrote:
Trying to simulate the drawing behavior of NSCell seems error-prone
to me. Since I don't have access to the original code, it would be
hard to match its behavior. I'd much rather inherit as muc
Right, agreed. Ken's idea was that I would implement my own
-drawInteriorWithFrame:inView:, which is what I was saying I didn't want
to do.
Seth Willits wrote:
On Feb 26, 2008, at 3:13 PM, John Stiles wrote:
Trying to simulate the drawing behavior of NSCell seems error-prone
to me. Since I
On Feb 26, 2008, at 3:13 PM, John Stiles wrote:
Trying to simulate the drawing behavior of NSCell seems error-prone
to me. Since I don't have access to the original code, it would be
hard to match its behavior. I'd much rather inherit as much as I can
and only customize around the edges.
Trying to simulate the drawing behavior of NSCell seems error-prone to
me. Since I don't have access to the original code, it would be hard to
match its behavior. I'd much rather inherit as much as I can and only
customize around the edges.
Ken Ferry wrote:
No, you'd draw whatever you feel l
No, you'd draw whatever you feel like drawing, possibly after
processing it. You'd use methods from NSStringDrawing. It's also
sometimes convenient to delegate drawing to what you think of as a
subcell - I'd try to do that before pulling tricks like temporarily
modifying self across a call to a s
What would I do in my override? Temporarily set the text color, call
super, and then revert it back?
Ken Ferry wrote:
The way NSCell deals with this is that the white color is never part
of the value data itself, it's thought of as a draw-time visual
effect.
That is, rather than calling setTe
The way NSCell deals with this is that the white color is never part
of the value data itself, it's thought of as a draw-time visual
effect.
That is, rather than calling setTextColor, you could override
-drawInteriorWithFrame:inView:.
-Ken
On Tue, Feb 26, 2008 at 11:35 AM, John Stiles <[EMAIL PR
Actually, for what it's worth, I did just hit one snag. If you attempt
to edit the cell, the field editor inherits the white color! This makes
it pretty difficult to see what you're doing ;)
I have a custom field editor anyway and have lots of control over how
the edit process gets started, so
Six of one and a half dozen of the other? :)
Anyway, it looks like this does the trick:
([cell isHighlighted] && [[outlineView window] isKeyWindow] &&
[[outlineView window] firstResponder] == outlineView)
Not quite as clean and nice as "backgroundStyle" but it will have to do
for now :)
Also, I'd be pretty surprised if this actually showed up in perf
profiling. Do you mean 'heavyweight', or annoying? :-)
> > but it seems a lot more heavyweight. You have to do:
> >
> > [[outlineView selectedRowIndexes] containsIndex:[outlineView
> rowForItem:item]]
-Ken
On Mon, Feb 25,
The pre-leopard code isn't pretty. The AppKit relnotes give the old
path while motivating the backgroundStyle API. I'm not sure if this
is 100% complete..
> Prior to Leopard, you may have noticed that text turns white in selected
> table view rows. The
> mechanism that controlled this behavior,
In my outline view, I'm using an NSTextFieldCell and setting the item's
color via setTextColor:.
This works fine, but for some colors, it's almost impossible to see when
the item is selected. I'd like to always make the text white if the item
is selected.
In Leopard, I know I can use [cell b
12 matches
Mail list logo
