In the end I’ve resorted to listening for frame changes in my tableview
subclass then I get the list of visible rows and force a redraw (via
setNeedsDisplay) on the row views. I also have to propagate this to the child
views which are the NSTextFields which were appearing black. Now I get an ugly
flash of black when the tableview first appears, but at least the rows which
get scrolled into view are drawn properly.
This feels really icky, and I shouldn’t need to be doing this, but….
Martin
On 25 Oct 2013, at 09:07 pm, Martin Hewitson <martin.hewit...@aei.mpg.de> wrote:
> Implementing this doesn’t seem to make any difference. I checked that it is
> called. In any case, the release notes say that responsive scrolling is not
> active if you link against 10.7, which I do.
>
> Martin
>
> On 25 Oct 2013, at 08:47 pm, Michael Cinkosky
> <mcinko...@thirdstreetsoftware.com> wrote:
>
>> I believe you need to implement a new delegate method for this table:
>>
>> +(BOOL) isCompatibleWithResponsiveScrolling {
>> return NO;
>> }
>>
>> https://developer.apple.com/library/prerelease/mac/releasenotes/AppKit/RN-AppKit/index.html#//apple_ref/doc/uid/TP30000741-CH2-SW28
>>
>> Michael
>>
>>
>>
>>
>> On Oct 25, 2013, at 12:41 PM, Martin Hewitson <martin.hewit...@aei.mpg.de>
>> wrote:
>>
>>> Dear list,
>>>
>>> I have a view-based tableview. In the row views there are some textfields
>>> which are a subclass of NSTextField. Since moving to 10.9, the textfields
>>> which are in rows which are out of view when the table loads are rendered
>>> all black when those rows are scrolled into view. This is new behaviour. Is
>>> this supposed to happen? In other words, did I miss some changes in the
>>> release notes which indicate I should do things differently now? Clicking
>>> in the offending textfields causes them to then draw properly. The reason I
>>> have subclassed NSTextField is because I draw them in different colours
>>> depending on the colour of the row background they are embedded in. My
>>> drawRect: is below, in case there is something fishy in there that might be
>>> causing this.
>>>
>>> Any one else seen this behaviour?
>>>
>>> Thanks,
>>>
>>> Martin
>>>
>>>
>>> - (void)drawRect:(NSRect)dirtyRect
>>> {
>>> NSView *superview = [self superview];
>>> [self setTextColor:[NSColor blackColor]];
>>> if ([superview respondsToSelector:@selector(startingColor)]) {
>>> NSColor *c = [superview
>>> performSelector:@selector(startingColor)];
>>> [self setTextColor:[c contrastingLabelColor]];
>>> [self setDrawsBackground:NO];
>>> NSBezierPath *path = [NSBezierPath
>>> bezierPathWithRoundedRect:NSInsetRect([self bounds], 0.5, 0.5) xRadius:5.0
>>> yRadius:5.0];
>>> [[c shadowWithLevel:0.1] set];
>>> [path stroke];
>>> if (mouseOver) {
>>> [[c highlightWithLevel:0.2] set];
>>> [path fill];
>>> }
>>> if ([[self currentEditor]
>>> respondsToSelector:@selector(setInsertionPointColor:)]) {
>>> [[self currentEditor]
>>> performSelector:@selector(setInsertionPointColor:) withObject:[c
>>> contrastingLabelColor]];
>>> }
>>> }
>>> [super drawRect:dirtyRect];
>>> }
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>
>>> 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:
>>> https://lists.apple.com/mailman/options/cocoa-dev/mcinkosky%40thirdstreetsoftware.com
>>>
>>> This email sent to mcinko...@thirdstreetsoftware.com
>>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
