Anyone having problems with your Custom NSView's inside a NSScrollView? I have a NSScrollView with a custom NSView that uses its draw(rect:) function to do all the work.
Before OSX 10.14, each time scrollview was marked with setNeedsDisplay, the documentView would also refresh. On OSX 10.14 I need to specifically mark the doucmentView to setNeedsDisplay too. Looks like its ignoring the NSScrollView.contentView.copiesOnScroll property.
Does anyone have similar issues or point me to release notes? the NSAppKit release notes don't say anything about NSScrollView.
We encountered the same problem. After several days of experimenting, the cause for the problem in our setup was as follows:
The documents we need to draw can be quite large. Therefore we optimised drawing in NSView's drawRect method to paint the visible portions of the document only, according to the clip-rectangle:
NSRect clipRect = [nsClipView bounds];
This worked great before Mojave.
Under Mojave our code would display black for the portions of the document that scrolled into the visible region.
We changed our drawing routines to display exactly the areas indicated by the 'dirty rectangle' of the drawRect method:
- (void)drawRect:(NSRect)dirtyRect
Now scrolling works under Mojave.
Related
My understanding was that viewForTableColumn:row: would be called only for rows that are visible.
I confirmed this using the following:
NSRange rowsInRect = [aTableView rowsInRect:[aTableView visibleRect]];
NSInteger lastVisibleRow = rowsInRect.location + rowsInRect.length;
But with Mavericks, viewForTableColumn:row is getting called many more times without scrolling down.
For example, if my last visible row was 35, data source method is called for 139 rows.
Can anybody explain this?
I found the explanation to this in AppKit Release notes for OS X v10.9.
Here goes:
Mac OS 10.9 has a new feature called Responsive Scrolling. Responsive Scrolling allows the application to continue to rapidly scroll content even when the application’s main thread is busy doing other work. AppKit accomplishes this by having the document view draw more than what is currently visible during idle.
To facilitate Responsive Scrolling, your document view will be asked to draw portions that are not currently visible to the user.
The following method is called by NSView with a 'rect' for a recommended area that should be fully rendered for overdraw. Override this method and bring in additional subviews and pre-cached content for the 'rect' in order to perform responsive scrolling.
To suppress overdraw for a particular view (such as NSTableView), override this method and call [super prepareContentInRect:[self visibleRect]].
(void)prepareContentInRect:(NSRect)rect;
I'm using a view based NSTableView which displays a NSTableRowView containing an NSImageView and some NSTextFields. The NSTextFields are having the backgroundColor property set and are drawing correctly. I've tried to draw them with rounded corners by setting
[textfield.layer setWantsLayer: YES];
[textfield.layer setCornerRadius: 5.];
What is working but causes the views with the applied corner radius to flicker while scrolling the table view. Setting the view's layer via textfield.layer [setLayer: [CALayer layer]] or forcing the layer to rasterize by setting [textfield.layer setShouldRasterize: YES] also did not work. Any suggestions how to get rid of the nasty flickering?
I'm developing on Mavericks for Mavericks using Xcode 5.
With the help of uchuugaka's post I was able to fix it using this tutorial: Tutorial
I have a 10.7 app built on 10.9. I'm debugging on 10.9.
My main view has a splitView with two panes: a webview in one, and an NSScrollView in the other.
When the app starts I programmatically move the divider to the right to hide the right-hand pane and the enclosed NSScrollView.
When this happens I get this warning in the console:
Layout still needs update after calling -[NSScrollView layout].
NSScrollView or one of its superclasses may have overridden -layout
without calling super. Or, something may have dirtied layout in the
middle of updating it. Both are programming errors in Cocoa
Autolayout. The former is pretty likely to arise if some pre-Cocoa
Autolayout class had a method called layout, but it should be fixed.
This only happens when the view is first loaded when the app starts. Switching away to a new view, and back, is fine.
I think the problem is that the scroll view is still being drawn when I move the splitView divider, causing the scrollview to be dirtied.
If I comment out the line that moves the divider I do not see the message.
FYI, I did not get the error when building / debugging on 10.8.
From Googling around the consensus seems to be that this is a bug in 10.9 and can be ignored, but I don't like to leave my code with warnings.
Does anyone know how I can fix this? I need to move the code that moves the divider to a point AFTER the view has been fully drawn.
Thanks
Darren.
I've got a custom NSTableHeaderView of custom NSTableHeaderCell objects that draw a custom header. The problem I'm having is that when the NSScroller bars show up, the header drawn above the scroller is the default, not my custom drawing.
Turns out the view that controls this section (over the scroller, right side of header) is called cornerView and the NSTableView has a -setCornerView:(NSView *)view method to set it. I fixed my problem by subclassing NSView and using custom drawing to draw a corner image into the view, then setting that subclass using the previously mentioned method.
Mac Mojave Left Corner View
Recently when providing support for one of my application on Mac Mojave I find out the culprit behind the top left corner view of table view. this can also be removed if we will set the corner view from xib like below.
This issue produces if Automatically Hide Scroller property is set to YES and no corner view has been set
Solution:
Please see attached image: http://i45.tinypic.com/fu8bpz.png
Has anyone every seen this kind of weird scroll bar behavior? I embedded a custom view in an NSScrollView. The scroll bars do not appear to be drawing correctly, and they also appear in the middle of my custom view. This happens on 10.6, yet not when I build on 10.7. I also see it on 10.8. I have tried fixing this by building in XCode 3.2 as well as XCode 4.3.
I was not balancing my [[NSGraphicsContext current] saveGraphicsState] with the appropriate [[NSGraphicsContext current] restoreGraphicsState]. Each [[NSGraphicsContext current] saveGraphicsState] must be balanced with a [… restoreGraphicsState] call, otherwise the GraphicsContext will be in an unpredictable state.