If I remove this method from my view everything works fine (no content disappears if I click on a button), so this is definitely the cause.
I'm trying to make a window that is rounded and has a gradient via the code below. Is there anything wrong with this at all that could cause content on the view to disappear?
- (void)drawRect:(NSRect)dirtyRect
{
[NSGraphicsContext saveGraphicsState];
NSBezierPath *outerClip = [NSBezierPath bezierPathWithRoundedRect:[self bounds]
xRadius:3.0
yRadius:3.0];
[outerClip setClip];
NSGradient* aGradient = [[NSGradient alloc]
initWithStartingColor:[NSColor colorWithCalibratedWhite:1.0 alpha:1.0]
endingColor:[NSColor colorWithCalibratedWhite:0.65 alpha:1.0]];
[aGradient drawInRect:[outerClip bounds] angle:270];
[NSGraphicsContext restoreGraphicsState];
}
Switching to NSGradient drawInbezierPath fixes the issue.
I know you answered your own question but I thought I would share why your content was vanishing with the above code.
When you use setClip you are removing the previous clipping path and replacing it with your new path. This means you will wind up drawing outside of the dirty area, thus overwriting previously drawn content.
I had the same issue with drawing rounded corners on my own splash screen, and eventually found a different way to do what I wanted.
Also, you can use the clipRect: class method of NSBezierPath to change the clipping path to the intersection of the existing path and the area you want to restrict drawing into. Of course, save and restore the graphics state around your call to clipRect:.
Related
I'm looking for a way to draw a fade effect on a table view (and outline view, but I think it will be the same) when the content is scrolled. Here is an example from the Fantastical app:
Also a video of a similar fade on QuickLook windows here.
To make this I tried subclassing the scrollview of a tableview with this code:
#define kFadeEffectHeight 15
#implementation FadingScrollView
- (void)drawRect: (NSRect)dirtyRect
{
[super drawRect: dirtyRect];
NSGradient* g = [[NSGradient alloc] initWithStartingColor: [NSColor blackColor] endingColor: [NSColor clearColor]];
NSRect topRect = self.bounds;
topRect.origin.y = self.bounds.size.height - kFadeEffectHeight;
topRect.size.height = kFadeEffectHeight;
NSRect botRect = self.bounds;
botRect.size.height = kFadeEffectHeight;
[NSGraphicsContext saveGraphicsState];
[[NSGraphicsContext currentContext] setCompositingOperation: NSCompositeDestinationAtop];
// Tried every compositing operation and none worked. Please specify wich one I should use if you do it this way
[g drawInRect: topRect angle: 90];
[g drawInRect: botRect angle: 270];
[NSGraphicsContext restoreGraphicsState];
}
...but this didn't fade anything, probably because this is called before the actual table view is drawn. I have no idea on how to do this :(
By the way, both the tableview and the outlineview I want to have this effect are view-based, and the app is 10.7 only.
In Mac OS X (as your question is tagged), there are several gotchas that make this difficult. This especially true on Lion with elastic scrolling.
I've (just today) put together what I think is a better approach than working on the table or outline views directly: a custom NSScrollView subclass, which keeps two "fade views" tiled in the correct place atop its clip view. JLNFadingScrollView can be configured with the desired fade height and color and is free/open source on Github. Please respect the license and enjoy. :-)
I have searched around and haven't found anything regarding this particular problem. I have a window with a vertical NSSplitView. Within the right view of the splitview, I have an NSBox object set to fill the contents of the view. I am loading in custom nibs using setContentView: to swap in views to the NSBox on the righthand side of the splitview. In my custom views I'm tying to fill the views with an NSColor object that uses a NSImage to pattern the background. All of this is working as expected. I am using the code based on this article: http://www.mere-mortal-software.com/blog/details.php?d=2007-01-08 to set the phase of the pattern to the top-left corner:
[[NSGraphicsContext currentContext] saveGraphicsState];
[[NSGraphicsContext currentContext] setPatternPhase: NSMakePoint( [self bounds].origin.x,
[self bounds].size.height )];
[[self leatherColor] set];
NSRectFill( [self bounds] );
[[NSGraphicsContext currentContext] restoreGraphicsState];
with the intention that the pattern appears to remain constant in the upper lefthand corner of the NSBox when the views are re-sized as would be the expected behavior (via the splitview moving or the window itself being resized). I have implemented this in a stripped-down test app with just a window and a custom view and it behaves as expected.
In my project with the splitview however, it is behaving like the patternPhase is being set on the upper lefthand corner of the entire window instead of the upper lefthand corner of the right-half of the splitview (i.e. it should shift with resizing the splitview) It behaves like it's "revealing a larger image instead of shifting with it. I'm pretty certain this is an issue with multiple coordinate spaces, me misunderstanding how the coordinates of an NSSplitView work, or something to do with the view hierarchy. From the documentation on NSGraphicsContext, in the setPatternPhase: method it says: "For example, setting the pattern phase to (2,3) has the effect of moving the start of pattern cell tiling to the point (2,3) in default user space." Will the default user space correspond with the bounds of my custom view, or could it be that I am creating the point based on the right side view set of coordinates and the setPatternPhase implements it for the full width of the spitview (including the left-half)?
Any suggestions/advice/help you could provide would be greatly appreciated.
Edit: I have uploaded a copy of the project so you can see the behavior: http://dl.dropbox.com/u/6679821/ViewSwitcher.zip
You need to adjust the phase depending on where the view sits in the window. I use this category on NSView:
#implementation NSView (RKAdditions)
- (void)rk_drawPatternImage:(NSColor*)patternColor inRect:(NSRect)rect
{
[self rk_drawPatternImage:patternColor inBezierPath:[NSBezierPath bezierPathWithRect:rect]];
}
- (void)rk_drawPatternImage:(NSColor*)patternColor inBezierPath:(NSBezierPath*)path
{
[NSGraphicsContext saveGraphicsState];
CGFloat yOffset = NSMaxY([self convertRect:self.bounds toView:nil]);
CGFloat xOffset = NSMinX([self convertRect:self.bounds toView:nil]);
[[NSGraphicsContext currentContext] setPatternPhase:NSMakePoint(xOffset, yOffset)];
[patternColor set];
[path fill];
[NSGraphicsContext restoreGraphicsState];
}
#end
In your case you'd modify -drawRect: to look like this:
-(void) drawRect: (NSRect)dirtyRect
{
[self rk_drawPatternImage:[self leatherColor] inRect:self.bounds];
}
I'm using NSImage's -lockFocusFlipped: method to do some drawing into an image. My code looks like this:
NSImage *image = [[NSImage alloc] initWithSize:NSMakeSize(256, 256)];
[image lockFocusFlipped:YES];
NSShadow *shadow = [[NSShadow alloc] init];
[shadow setShadowColor:[NSColor blackColor]];
[shadow setShadowBlurRadius:6.0];
[shadow setShadowOffset:NSMakeSize(0, 3)];
[shadow set];
NSRect shapeRect = NSMakeRect(0, 0, 256, 100);
[[NSColor redColor] set];
NSRectFill(shapeRect);
[image unlockFocus];
This code works to a certain point. I can confirm that the context is indeed flipped because [[NSGraphicsContext currentContext] isFlipped] returns YES, and also because shapeRect is drawn at the right position (using the top left corner as the origin). That said, the NSShadow does not seem to respect the flipped status of the context. Setting the shadow offset to (0, 3) should move the shadow down when the context is flipped, but it actually moves it up (which is what would happen in a standard non-flipped context).
This problem seems specific to -lockFocusFlipped, because when I'm drawing using this same code into a CALayer with a flipped coordinate system, the shadow is drawn just fine (respecting the flip). Documentation on -lockFocusFlipped also seems to be quite vague. This is all it says in the NSImage class documentation:
Prepares the image to receive drawing commands using the specified flipped state.
And I also found this note in the Snow Leopard AppKit Release Notes:
There are cases, for example drawing directly via NSLayoutManager, that require a flipped context. To cover this case, we add
- (void)lockFocusFlipped:(BOOL)flipped;
This doesn't alter the state of the image itself, only the context on which focus is locked. It means that (0,0) is at the top left and positive along the Y-axis is down in the locked context.
None of the docs seem to explain NSShadow's behaviour in this case. And through further testing, it seems NSGradient does not seem to respect the flipped state of the drawing context used by NSImage either.
Any insight is greatly appreciated :-)
From the NSShadow class reference:
Shadows are always drawn in the default user coordinate space, regardless of any transformations applied to that space. This means that rotations, translations and other transformations of the current transformation matrix (the CTM) do not affect the resulting shadow.
And that's what flipping ultimately is: Translate up, scale back the other way.
There's no such statement for NSGradient, so I'd suggest filing a bug about that one.
Various things, including (perhaps most notably) the window losing its main status and then being brought back into focus, cause some of my custom views to develop rendering glitches until I do something (such as resize the window) to cause these custom views to redraw. I assume this is due to some sort of caching bug in AppKit, and I'm sure I'm not the only one getting this behaviour, so does anyone know how to work around it?
Here's an example:
Notice the weird dark line at the left of the view's background? This is drawn even without the subviews in the view. I get other similar bugs in some of my other views.
Here's the code that does the drawing:
void EDDrawGlossEffectInRect(NSRect dirtyRect) {
NSRect topRect, bottomRect;
NSDivideRect(dirtyRect, &topRect, &bottomRect, (dirtyRect.size.height / 2), NSMaxYEdge);
[EDLightChromeColor set];
NSRectFill(topRect);
[EDMidChromeColor set];
NSRectFill(bottomRect);
}
and
-(void)drawRect:(NSRect)dirtyRect {
EDDrawGlossEffectInRect(dirtyRect);
NSBezierPath *path = [NSBezierPath bezierPath];
[path setLineWidth:1.0];
NSPoint startPoint = {0, dirtyRect.size.height};
NSPoint endPoint = {dirtyRect.size.width, dirtyRect.size.height};
[path moveToPoint:startPoint];
[path lineToPoint:endPoint];
[[NSColor colorWithCalibratedWhite:0.7 alpha:1] set];
[path stroke];
}
The view is created programatically, not with Interface Builder, which I'm not using for this project.
dirtyRect will not necessarily cover your view's visible rect, so you might want to see which part of your view's bounds intersect with the dirtyRect and just repaint that. Otherwise, just repaint the bounds of the view. Resizing the window can cause the entire bounds to be dirty (usually), which is probably why you're seeing full repaints at that point.
I am making custom NSScrollers for use in NSScrollView. But when any of the superviews of the NSScroller gets Core Animation enabled. I get this drawing issue that's a huge nuisance. Whenever i scroll into the corners of the scroll view the scrollers clip. But if a scroller starts out drawing in the corner, the scroller part stays in that corner. What could be causing this problem? I have too much code to show on here. But here is my drawing code:
NSRect knobRect = [self rectForPart:NSScrollerKnob];
NSBezierPath *path = [NSBezierPath bezierPathWithRoundedRect:knobRect
xRadius:CornerRadius
yRadius:CornerRadius];
[path setLineWidth:2];
[[NSColor colorWithDeviceRed:0.114 green:0.114 blue:0.114 alpha:0.3] set];
[path fill];
[[NSColor colorWithDeviceWhite:1.0
alpha:0.100] set];
// Clip drawing to this path; draw nothing outwith the path.
[path addClip];
[path stroke];
I already tried to get rid of everything except the fill but it didnt work. This issue goes away if I call setNeedsDisplay:YES on the super view when setFloatValue is called.
Clipping Issue http://idkz.org/b814ee5c875c9f44cc2d1345e4489420
it seems that the answer to the problem seems to be to call:
[self setArrowsPosition:NSScrollerArrowsNone];
And it magically works :D
Edit, but I get a similar effect when I drag the scrollbar. :'( Is there anyway to clear the graphics without redrawing the scrollview itself? :(
You probably found this out by know, but in your case, the following piece should solve your drawing issue:
-(BOOL)isOpaque {
return NO;
}