NSTableView Cell Display Issue - objective-c

I'm using a view-based NSTableView, and I've ran across a little issue.
I'm trying to switch the text color of my two labels from black to white when highlighted.
To do so, I've written the following code,
- (void)tableViewSelectionDidChange:(NSNotification *)notification
{
NSView * viewInQuestion = [table viewAtColumn:0 row:[table selectedRow] makeIfNecessary:YES];
if ([viewInQuestion isNotEqualTo:lastViewSelected])
{
[(NSTextField*)lastViewSelected.subviews.lastObject setTextColor:NSColor.blackColor];
[(NSTextField*)[lastViewSelected.subviews objectAtIndex:1] setTextColor:NSColor.grayColor];
}
[(NSTextField*)viewInQuestion.subviews.lastObject setTextColor:NSColor.whiteColor];
[(NSTextField*)[viewInQuestion.subviews objectAtIndex:1] setTextColor:NSColor.whiteColor];
lastViewSelected = viewInQuestion;
}
That works great; I get this result:
The issue is that sometimes the text doesn't appear white even though an NSLog told me that the NSTextField's color was NSCalibratedWhite (or whatever it's called).
The color also switches back to black when the textField is not visible (scrolling away from it and then back). Yet again, even when it does this, the NSTextField's color is still logged as white.

Overriding setBackgroundStyle on NSTableViewCell has worked perfectly for me, at least on OS X 10.8. (Given the number of relevant questions here on SO, one can guess that there used to be some problems before.)
The background style is updated on selection events and on window activation/deactivation, just as one would expect.
Here's my custom cell impl — as trivial as it can get:
#implementation RuntimeInstanceCellView
- (void)setBackgroundStyle:(NSBackgroundStyle)backgroundStyle {
[super setBackgroundStyle:backgroundStyle];
self.detailTextField.textColor = (backgroundStyle == NSBackgroundStyleLight ? [NSColor darkGrayColor] : [NSColor colorWithCalibratedWhite:0.85 alpha:1.0]);
// self.detailTextField.textColor = (backgroundStyle == NSBackgroundStyleLight ? [NSColor blackColor] : [NSColor whiteColor]);
}
#end

My method is very hacky, and probably not the optimal solution; But it resolves it so that's good.
Assuming you implemented tableSelectionDidChange the way I have, all you need to do is register an NSNotification and implement a custom method that should be more explicit.
In the init, awake, or didFinishLaunching part of your application...
NSView * contentView = table.enclosingScrollView.contentView;
[contentView setPostsFrameChangedNotifications:YES];
[NSNotificationCenter.defaultCenter addObserver:self selector:#selector(boundsDidChange:) name:NSViewBoundsDidChangeNotification object:contentView];
Somewhere else in the program...
(assuming hasUpdatedCell is a BOOLEAN property)
- (void)boundsDidChange:(NSNotification *)notification
{
/* Bounds can change while nothing is selected--> but we only want to execute the method if a cell is selected. */
if ([table selectedRow] == -1) {return;}
NSRect visibleRect = table.enclosingScrollView.visibleRect;
NSView * viewInQuestion = [table viewAtColumn:0 row:[table selectedRow] makeIfNecessary:YES];
NSPoint selectedViewOrigin = [viewInQuestion convertPoint:viewInQuestion.frame.origin toView:table.enclosingScrollView];
/* If the selected cell is visible, then we can go ahead and redraw the white text as a part of the workaround.
This is because scrolling away from the selected cell and back will make the cell revert back to black. */
BOOL cellVisible = NSPointInRect(selectedViewOrigin, visibleRect);
/* We already know we need to update it, and we will so we don't need to evaluate the next step in the program */
if (!cellVisible && !hasUpdatedCell) {return;}
if (cellVisible && !hasUpdatedCell)
{
/* The cell is visible but we haven't updated. Let's do it then. */
[self tableViewSelectionDidChange:nil];
hasUpdatedCell = YES;
}
else if (!cellVisible)
{
/* The cell is not visible and we need to update next time. */
hasUpdatedCell = NO;
}
}
Things then should get displayed properly.

Related

NSScrollView: fade in a top-border like Messages.app

What I Want to Do:
In Messages.app on OS 10.10, when you scroll the left-most pane (the list of conversations) upwards, a nice horizontal line fades in over about 0.5 seconds. When you scroll back down, the line fades back out.
What I Have:
I am trying to achieve this effect in my own app and I've gotten very close. I subclassed NSScrollView and have done the following:
- (void) awakeFromNib
{
_topBorderLayer = [[CALayer alloc] init];
CGColorRef bgColor = CGColorCreateGenericGray(0.8, 1.0f);
_topBorderLayer.backgroundColor = bgColor;
CGColorRelease(bgColor);
_topBorderLayer.frame = CGRectMake(0.0f, 0.0f, self.bounds.size.width, 1.0f);
_topBorderLayer.autoresizingMask = kCALayerWidthSizable;
_topBorderLayer.zPosition = 1000000000;
_fadeInAnimation = [[CABasicAnimation animationWithKeyPath:#"opacity"] retain];
_fadeInAnimation.duration = 0.6f;
_fadeInAnimation.fromValue = #0;
_fadeInAnimation.toValue = #1;
_fadeInAnimation.removedOnCompletion = YES;
_fadeInAnimation.fillMode = kCAFillModeBoth;
[self.layer insertSublayer:_topBorderLayer atIndex:0];
}
- (void) layoutSublayersOfLayer:(CALayer *)layer
{
NSPoint origin = [self.contentView documentVisibleRect].origin;
// 10 is a fudge factor for blank space above first row's actual content
if (origin.y > 10)
{
if (!_topBorderIsShowing)
{
_topBorderIsShowing = YES;
[_topBorderLayer addAnimation:_fadeInAnimation forKey:nil];
_topBorderLayer.opacity = 1.0f;
}
}
else
{
if (!_topBorderIsShowing)
{
_topBorderIsShowing = NO;
// Fade out animation here; omitted for brevity
}
}
}
The Problem
The "border" sublayer that I add is not drawing over top of all other content in the ScrollView, so that we end up with this:
The frames around the image, textfield and checkbox in this row of my outlineView are "overdrawing" my border layer.
What Causes This
I THINK this is because the scrollView is contained inside an NSVisualEffectView that has Vibrancy enabled. The reason I think this is that if I change the color of my "border" sublayer to 100% black, this issue disappears. Likewise, if I turn on "Reduce Transparency" in OS X's System Preferences > Accessibility, the issue disappears.
I think the Vibrancy compositing is taking my grey border sublayer and the layers that represent each of those components in the outlineView row and mucking up the colors.
So... how do I stop that for a single layer? I've tried all sorts of things to overcome this. I feel like I'm 99% of the way to a solid implementation, but can't fix this last issue. Can anyone help?
NB:
I am aware that it's dangerous to muck directly with layers in a layer-backed environment. Apple's docs make it clear that we can't change certain properties of a view's layer if we're using layer-backing. However: adding and removing sublayers (as I am) is not a prohibited action.
Update:
This answer, while it works, causes problems if you're using AutoLayout. You'll start to get warnings that the scrollView still needs update after calling Layout because something dirtied the layout in the middle of updating. I have not been able to find a workaround for that, yet.
Original solution:
Easiest way to fix the problem is just to inset the contentView by the height of the border sublayer with this:
- (void) tile
{
id contentView = [self contentView];
[super tile];
[contentView setFrame:NSInsetRect([contentView frame], 0.0, 1.0)];
}
Should have thought of it hours ago. Works great. I'll leave the question for anyone who might be looking to implement these nice fading-borders.

Editable transparent NSTextField text appears with white highlight

I am trying to create editable transparent NSTextField in a semi transparent window:
What I have noticed is that whenever the field is editable there is a white "selection like" background drawn even though the element is not actually selected.
Additional observable symptoms:
This highlight is not present when the field is set as non-editable.
If there are multiple fields only the first one has the highlight.
The highlight is not present if the text is not set programmatically
Following code was used to generate the field:
f = [[NSTextField alloc] initWithFrame:b2];
f.backgroundColor = [NSColor clearColor];
f.drawsBackground = YES;
f.bordered = NO;
f.bezeled = NO;
f.focusRingType = NSFocusRingTypeNone;
f.textColor = [NSColor whiteColor];
f.editable = YES;
f.selectable = YES;
f.backgroundColor = [NSColor clearColor];
f.allowsEditingTextAttributes = YES;
f.stringValue = #"Foo";
[self.contentView addSubview:f];
Additional observations (potentially a separate problem):
When field is not the first field on the screen and the initial text is set programmatically and removed by editing the field there is a shadow of the text:
I can't seem to find any documentation on this I wonder if any of you have had this happen and potentially have a solution or a pointer to docs I might have not stumbled upon.
part 1: removing highlight
there are two options here depending on the behavior you are looking for
option 1 - nil first responder
TextField is not first responder
No highlighted text
No Cursor at the end of text
Assuming you are using an NSWindow, set the first responder to nil after calling makeKeyAndOrderFront
[self.window makeKeyAndOrderFront:self];
[self.window makeFirstResponder:nil];
It appears as though makeKeyAndOrderToFront: looks for the first NSResponder in the window willing to accept first responder. Then becomeFirstResponder is called on that responder; leading to option 2
option 2 - override becomeFirstResponder
TextField is first responder
No highlighted text
Cursor appears at the trailing edge of text
Subclass NSTextfield and override it's becomeFirstResponder method
#implementation BPTextField
- (BOOL)becomeFirstResponder {
BOOL isResponder = [super becomeFirstResponder];
//Get Field editor, set selected range
NSText* fieldEditor = [[self window] fieldEditor:YES forObject:self];
[fieldEditor setSelectedRange:NSMakeRange(fieldEditor.string.length ,0)];
return isResponder;
}
#end
I prefer this option from a usability perspective
part 2: removing shadow
option 1 - add a solid background color
I'm not clear ; ) on why this is the case, but if you add a solid background color, the text will update.
option 2 - override textDidChange
override textDidChange:notification in your textfield
#implementation BPTextField
- (void)textDidChange:(NSNotification *)notification {
[super textDidChange:notification];
[self setNeedsDisplay:YES];
}
#end
Final notes
You'll notice that the text looks bad, or rigid. Adding a background color to the textfield, or to the superview's layer will fix this.
This is an answer to part 2 of the question.
The shadow artifact is from rendering window's shadow which is not updated when the text in the NSTextField changes.
If the window's hasShadow method returns "NO" the text's shadow will not create shadow for the text either.

Losing selection highlight in NSOutlineView subclass

To customize the default blue gradient highlight style I made a subclass of NSOutlineView and overrode the method -highlightSelectionInClipRect, like so:
- (void)highlightSelectionInClipRect:(NSRect)theClipRect
{
NSRange aVisibleRowIndexes = [self rowsInRect:theClipRect];
NSIndexSet *aSelectedRowIndexes = [self selectedRowIndexes];
NSInteger aRow = aVisibleRowIndexes.location;
NSInteger anEndRow = aRow + aVisibleRowIndexes.length;
for (int aRow; aRow < anEndRow; aRow++) {
if([aSelectedRowIndexes containsIndex:aRow]) {
// draw gradient
}
}
}
This works fine, but sometimes the background is not drawn. On the screenshot below you can see how the selection highlight is not drawn when clicking on the first item after the last one was selected.
It seems as if this only happens if the new selected item is not directly beneath or above the old selected one. Selecting five items in the order 1-2-3-4-5-4-3-2-1 always draws the appropriate background, anything else (e.g. 1-2-5) not.
Why is this happening? If you need any more details I will be glad to add some more code, but at the meantime I have no clue where to search for this behaviour.
here is my (very simple) solution using blocks:
- (void)highlightSelectionInClipRect:(NSRect)clipRect
{
[[self selectedRowIndexes] enumerateIndexesUsingBlock:^(NSUInteger idx, BOOL *stop)
{
// draw gradient
}];
}

Moving the field editor

I have an NSTableView subclass with a little animation on it that sometimes changes the width of its columns. It works fine, but if one of the cells is being edited at the time, the field editor stays where it is and does not match the new frame of the cell as it is resized. Whenever I animate the columns, I call the following function in the NSTableView subclass:
- (void) updateFieldEditorPosition {
if([self editedRow]!= -1 && [self editedColumn] != -1) {
NSText *fieldEditor = [[self window] fieldEditor:NO forObject:self];
NSRect editedCellFrame = [self frameOfCellAtColumn:[self editedColumn] row:[self editedRow]];
if(!NSEqualRects([fieldEditor frame], editedCellFrame)) {
[fieldEditor setFrame:editedCellFrame];
[fieldEditor setNeedsDisplay:YES];
[self setNeedsDisplay:YES];
}
}
}
Unfortunately, this doesn't seem to do anything. I have checked that I am, indeed, receiving the correct field editor, and through the debugger I can see that the field editor's frame is being set to the right value and changes over time, but it never actually moves on-screen. What am I missing?
EDIT:
So, I've made an interesting discovery. If, at the same time that I set the NSTableColumn's width, I also set it as hidden and then unhide it again, the field editor moves along with it!
[tableColumn setWidth:newWidth];
[tableColumn setHidden:YES];
[tableColumn setHidden:NO];
I don't know what boolean is getting flipped when I set the NSTableColumn as hidden, but it's working and the field editor is updating itself. It's not the NSTableView's needsDisplay, because if I set that instead of hiding the column nothing happens. Can anyone explain this to me so I can do it a little more elegantly?

UITableViewCell subclass, drawn in code, animate Delete button in

I'm working on a custom UITableViewCell subclass, where everything is drawn in code rather than using UILabels etc. (This is part learning exercise and partly because drawing in code is much faster. I know that for a couple of labels it wouldn't make a huge difference, but eventually I'll want to generalise this to more complex cells.)
Currently I'm struggling with the delete button animation: how to animate the cell shrinking as the delete button slides in.
Firstly, I am drawing in a custom subview of the cell's contentView. Everything is drawn in that one subview.
I am setting the subview's size by catching layoutSubviews on the cell itself, and doing:
- (void)layoutSubviews
{
[super layoutSubviews];
CGRect b = [self.contentView bounds];
[subcontentView setFrame:b];
}
I'm doing this rather than just setting an autoresizing mask because it seemed more reliable in testing, but I can use the autoresizing mask approach in testing if needed.
Now, the default thing that happens when someone hits the minus is the view gets squished.
I can avoid that by, when setting up my cell, calling
subcontentView.contentMode = UIViewContentModeRedraw;
That gives me the correct end result (my custom view redraws with the new size, and is laid out properly, like the first image I posted), but the animation of the transition is unpleasant: it looks like the cell stretches and shrinks back to size.
I know why the animation is working like that: Core Animation doesn't ask your view to redraw for each frame, it gets it to redraw for the end position of the animation and then interpolates to find the middle bits.
Another solution is to do
subcontentView.contentMode = UIViewContentModeLeft;
That just draws the delete button over my cell, so it covers part of it.
If I also implement
- (void) didTransitionToState:(UITableViewCellStateMask)state
{
[self setNeedsDisplay];
}
then once the delete button has slid in the cell 'jumps' to the correct size. That way there's no nice slidey animation, but at least I get the correct result at the end.
I guess I could run my own animation in parallel with the delete button appearing, temporarily creating another view with a copy of the image of my view in the old size, setting mine to the new size, and fading between them — that way there would be a nice cross fade instead of a sharp jump. Anyone use such a technique?
Now, you might ask why I can't use the contentStretch property and give it a region to resize. The problem with that is I'm making something to be reasonably generic, so it's not always going to be possible. In this particular example it'd work, but a more complex cell may not.
So, my question (after all of this background) is: what do you do in this situation? Does anyone have the animating delete button working for custom drawn cells? If not, what's the best compromise?
This worked for me finally. in subclass of UITableViewCell
subDrawContentView.contentMode = UIViewContentModeLeft;
overide layout subviews method
- (void)layoutSubviews {
CGRect b = [subDrawContentView bounds];
b.size.width = (!self.showingDeleteConfirmation) ? 320 : 300;
[subDrawContentView setFrame:b];
[subDrawContentView setNeedsDisplay];
[super layoutSubviews];
}
So I will paste the code first and then I will explain:
-(void)startCancelAnimation{
[cancelButton setAlpha:0.0f];
[cancelButton setFrame:CGRectMake(320., cancelButton.frame.origin.y, cancelButton.frame.size.width, cancelButton.frame.size.height)];
cancelButton.hidden=NO;
[UIView animateWithDuration:0.4
animations:^(void){
[progressView setFrame:CGRectMake(progressView.frame.origin.x, progressView.frame.origin.y, 159.0, progressView.frame.size.height)];
[text setFrame:CGRectMake(text.frame.origin.x, text.frame.origin.y, 159.0, text.frame.size.height)];
[cancelButton setFrame:CGRectMake(244., cancelButton.frame.origin.y, cancelButton.frame.size.width, cancelButton.frame.size.height)];
[cancelButton setAlpha:1.0f];
} ];
}
-(void)stopCancelAnimation{
[UIView animateWithDuration:0.4
animations:^(void){
[cancelButton setFrame:CGRectMake(320., cancelButton.frame.origin.y, cancelButton.frame.size.width, cancelButton.frame.size.height)];
[cancelButton setAlpha:0.0f];
}completion:^(BOOL completion){
cancelButton.hidden=YES;
[cancelButton setAlpha:1.0f];
[progressView setFrame:CGRectMake(progressView.frame.origin.x, progressView.frame.origin.y, DEFAULT_WIDTH_PROGRESS, progressView.frame.size.height)];
[text setFrame:CGRectMake(text.frame.origin.x, text.frame.origin.y, DEFAULT_WIDTH_TEXT, text.frame.size.height)];
}
];
}
-(void)decideAnimation{
if([cancelButton isHidden]){
[self startCancelAnimation];
}
else{
[self stopCancelAnimation];
}
}
So what I have there is a button that looks like this:
I have an IBOutlet to it. And what I am doing is resizing a UIProgressView and a UITextField (you can resize whatever you want). As for the code is pretty simple, but if you need any help to understand what's going on, please ask. Also, don't forget to add the Swip Gesture to the UITableView... Like this:
UISwipeGestureRecognizer *gesture = [[UISwipeGestureRecognizer alloc] initWithTarget:self action:#selector(didSwipe:)];
gesture.numberOfTouchesRequired=1;
gesture.direction = UISwipeGestureRecognizerDirectionRight;
[table addGestureRecognizer:gesture];
[gesture release];
Finally the method that does it all:
-(void)didSwipe:(UIGestureRecognizer *)gestureRecognizer {
if (gestureRecognizer.state == UIGestureRecognizerStateEnded) {
//Get the cell of the swipe...
CGPoint swipeLocation = [gestureRecognizer locationInView:self.table];
NSIndexPath *swipedIndexPath = [self.table indexPathForRowAtPoint:swipeLocation];
UITableViewCell* swipedCell = [self.table cellForRowAtIndexPath:swipedIndexPath];
//Make sure its a cell with content and not an empty one.
if([swipedCell isKindOfClass:[AMUploadsTableViewCell class]]){
// It will start the animation here
[(AMUploadsTableViewCell*)swipedCell decideAnimation];
// Do what you want :)
}
}
}
So as you can see the whole animation is created manually, so you can control exactly what you want. :)