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.
Related
This is similar to How to fix NSTextView's weird sizing inside a magnified NSScrollView, but I seem to have a slightly different problem, and the suggested solution does not work for me.
Basically, I have an NSTextView inside an NSScrollView with magnification. Zooming in with a pinch-and-zoom gesture and then resizing the window causes a crash with the error The window has been marked as needing another Display Window pass, but it has already had more Display Window passes than there are views in the window.
I have made a video illustrating the problem here: https://youtu.be/M_JRQI2oDaY
The project is here: https://github.com/angstsmurf/spatterlight/tree/helpviewtest
(The branch helpviewtest is a cut down test case created for this problem.)
I don't know if this is a bug with AutoLayout or Xcode but I've realised that if I run my application on a device which isn't the same size as the device in my storyboard, the elements are adopting the incorrect size.
I.e. Selecting View as iPhone SE and running the application on an iPhone 7+ The size of my tableview is the width of an iPhone SE screen, this fixes itself when I reload the view and then it then adopts the width of the iPhone 7+ screen.
Just a note as well the table view doesn't have a fixed width and is pinned to the top, bottom, left and right with 0 spacing and also I'm changing the height of the cells programmatically in code if this could affect it at all as well.
Video: https://drive.google.com/open?id=0B0QLbDLfJn6_YzljUGg4RTUwaTg
Views that come from a xib (or storyboard) have their IB frame values when they are created, before they are added to the view hierarchy. So a case like you describe is probably that something is accessing a view loaded from a xib before it has become part of the layout process and resized.
This would also explain why it's fixed when you go away and come back. The first time, it got the values before they were final, but the second time the values are already final and correct.
Layout code called fromviewDidLoad() for view controllers, or awakeFromNib() or initWith(coder:) for views is the likely cause. Layout code called from viewDidLoad() is especially problematic because it was fine up to iPhone 5s, but would now cause this problem.
It's impossible to say what exactly the issue just from this. From the NSLog statements visible in the video, the issue is whatever code calls that "weather view width". That is being called too early in the layout process. It needs to go in viewWillAppear or viewWillLayoutSubviews to make sure the correct values are ready for whatever calculation is dependent on that. Hope this helps.
I can't seem to recreate this. I would recommend double checking for any updates for Xcode and the Developer tools (softwareupdate --install -a).
Incase you haven't, restart Xcode.
EDIT: Disregard this answer, please read Mike Sand's post.
Try self.view.layoutIfNeeded in viewDidLoad or in viewWillAppear
I'm trying to get the split view controller working properly but apparently there's a bug in there or I'm missing something.
First of all, I've started a blank OSX Obj-C application, and in the Storyboard I've dragged the split view controller. Next, I've linked the segues from the main window controller to the split view and added two labels.
http://i.imgur.com/dlFObaF.png
When I build the project, it shows only the second page. Not to mention strange window size in the final build.
http://i.stack.imgur.com/IqRqr.png
I've tried everything.
This occurs in both vertical and horizontal split view.
Any suggestions?
I had the same issue myself today, but it's just the split line wasn't initiated properly.
To see, this, once you run your app, move your mouse toward the edge of the window and drag it, you will now see another view emerging.
To my best knowledge, I do not know how to fix this in IB or in code. Apparently NSSplitViewController does not have a property like UISplitViewControllerAutomaticDimension. Would appreciate if someone can contribute to this.
Edited: Found an answer via another thread. Basically, try to add some constraints to the subviews inside each view and that should prevent the size of a view to be zero. In my toy example, adding margin constraints to my buttons worked out well.
I am using autolayout feature for my mac app.I have enabled autolayout for my mainWindow & also for its child views.But on expanding window , only my window expands in size but not the child views.And on app launch I get following message in the console
"Layout still needs update after calling -[WebHTMLView layout]. WebHTMLView 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."
Please help!
The log is probably not related to your issue.
For your issue, select a view that you expect to stay pinned to the side of your window but isn't. You should see the constraints involving that view drawn as blue. It'll stay pinned if and only if you see a constraint there that pins it. You can explicitly add constraints with the Editor > Align and Editor > Pin menus.
The log is because web view implements that method and needs to rev, but it's mostly[1] harmless.
[1] Possibly html layout in the web view ends up triggering more often than necessary.
Did you check if
WebHTMLView or one of its superclasses may have overridden -layout
without calling super.
like the error text explains? WebHTMLView is your class?
As they say:
The former is pretty likely to arise if some pre-Cocoa Autolayout
class had a method called layout, but it should be fixed.
Unfortunately this is hard for me to test myself because I have yet to get a Magic Mouse of my own, but I've been told by my testers who do have a magic mouse that momentum scrolling isn't working in my app. I've not subclassed NSScrollView, but scrollview's document view is all custom. I have not overridden scrollWheel: anywhere, either, and yet momentum apparently just isn't working. I'm not even sure where to begin. I thought it'd just send scrollWheel events and things would take care of themselves. (Scrolling with a wheel or on the MBP trackpad works as expected.) Obviously I must somehow be doing something that's stopping it, but I don't even know where to begin. Thoughts?
I figured this out awhile ago and the problem was that on scroll, I was doing a lot of fancy view manipulation somewhat like how on the iPhone the UITableView adds and removes views as they scroll on and off screen. This worked great for performance - but the more I got into OSX programming, the more I realized this was wrong for OSX (but the right idea of iPhone).
Anyway, what's really going on, it seems, is that when you do something like a wheel scroll, the scroll event is sent to the view that's under the mouse cursor and then it ripples down the responders/views until it gets somewhere that handles it. Normally this isn't a problem, but with momentum scrolling the OS is really just sending ever smaller scrollWheel events to the view that was under the cursor at the time the momentum started. That means if the view is removed during the course of scrolling (because it scrolls off screen or something), it breaks the chain and the momentum stops because the view that's still getting the scrollWheel messages is no longer in the view hierarchy.
The "simple" fix is to not remove the view that got the last scrollWheel event - even if it's off screen. The better fix (and the one I went with) is to not try to use NSViews like they are UIViews and instead just draw the content using drawRect. :) Not only is that about a billion times faster, it Just Works(tm) with momentum scrolling because it's how OSX expects things to be done.
Repeat after me: OSX is not iPhoneOS.. :P
Odd scrolling behavior can occur when you don't set the Line Scroll and Page Scroll properties of the NSScrollView itself.
Beyond that, you're quite simply going to have to get a Magic Mouse - easily said or not :-) - to test this yourself or post the entire code of your custom view as well as the xib containing it. There's no way others can offer you more than guesses (like the above) without it.