Problem using autolayout feature of Mac os Lion - cocoa

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.

Related

Layout still needs update after calling NSTableRowView layout

I have two NSTableView's in my app and the user can drag and drop items from table A to table B. When dragging an item to table B Xcode gives me the following layout warning message:
Layout still needs update after calling -[NSTableRowView layout].
NSTableRowView 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 ever only happens when items are dragged to table B. I have otherwise no auto-layout warnings in IB and everything in the layout looks like being set up correctly. Does somebody know what the above message is trying to tell me? The tables are using standard Cocoa classes (not sub-classed).
I fixed it (or rather worked around it) by having the drop operation type not being allowed except for NSTableViewDropOperation.Above. Before a user could drop them onto other rows, not just between rows. But I want them to be only be allowed to be dropped between rows so that's fine with me. Here's the code that fixed it:
func tableView(aTableView:NSTableView, validateDrop info:NSDraggingInfo, proposedRow row:Int, proposedDropOperation operation:NSTableViewDropOperation) -> NSDragOperation
{
if (operation == .Above) { return .Move; }
return .None;
}
In my case the warning was slightly different.
Layout still needs update after calling -[NSView layout]. NSView 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.
Different class NSView.
Anyway in my case, I could fix this by setting translatesAutoresizingMaskIntoConstraints == false of a NSScrollView.
For the record, autoresizingMask and autoresizesSubviews don't need to be touched at all.
The warning simply means that I have to set the property manually, otherwise it will produce wrong constraints. But figuring out the problematic object was very hard. I had to iterate all view nodes to check the property state.

Not using Auto Layout, yet see 'Unable to simultaneously satisfy constraints' error

I'm not using Auto Layout in any of my nib files. I'm loading a NSViewController and then adding its view to another NSView manually. However when I do that, I am seeing this error:
Unable to simultaneously satisfy constraints
This makes no sense to me since I don't have autolayout enabled anywhere. I have specifically disabled it. I have control over the NSViewController being loaded and the NSView I'm adding it's view to. What can I do to fix this?
Auto layout is enabled (or not) at the window level. If any view in the window has had constraints added to it or overrides +requiresConstraintBasedLayout to return YES, then auto layout is enabled for the window. Any views which are not coded to participate in auto layout would probably have translatesAutoresizingMaskIntoConstraints left on, so they would still work just as they would in a springs-and-struts window.
It's possible that, under certain circumstances, Cocoa might add constraints. Certain Cocoa views, such as NSStackView, return YES from +requiresConstraintBasedLayout.
Are you using some of the most recent features in your window, such as title bar accessories?

Mac OS X Autolayout - expand to fill superview

I have a nib. It has an NSScrollView with an NSTableView inside it. I would like this tableview to automatically expand to fill its entire superview.
I'm trying to use autolayout but I have no idea how to add the constraints. Since the nib has no view objects other than the scroll view - I don't get how you reference the superview.
None of the auto layout buttons at the bottom of the nib editor give me any options, everything is grayed out.
I'm using Interface Builder, Xcode 5, OS X 10.9.2.
Not iOS!
You can't. But you probably have the code where this view controller is instantiated. There you need to add constraints manually.
To get started have a look at the WWDC sessions, in particular
Auto Layout by Example (https://developer.apple.com/videos/wwdc/2012/)
Best Practices for Mastering Auto Layout (https://developer.apple.com/videos/wwdc/2012/)
The learning curve is a bit steep but it'll be worth your while.
Check out the Content Hugging setting for your view to make sure it's allowed to expand.
Also check the warnings in the Interface Builder editor and let it add missing constraints if you're not sure what to do.
And always pay attention to the Autolayout warnings in the Xcode console!
This blog post has some nice hints as well:
http://oleb.net/blog/2013/03/things-you-need-to-know-about-cocoa-autolayout/
Some more specific tips:
Autolayout is enabled for your .nib/.xib, right? Just making sure.
The super view is referenced kind of implicitly when you set the constraints for your view, you don't set constraints for the top-level view in the .xib (if I recall correctly, no Xcode at hand right now).

Autolayout error with NSSplitView When Divider Programmatically Moved

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.

Another Cocoa: Crash in _NSDisplayOperationStack; Need Guidance too

Much like the question asked here, I too have problems with the NSDisplayOperationStack.
Let me make the context clear first though.
I have a window which contains a view, in there a tabView with several buttons, textviews and labels. The view inside of the tabview originates from a different NIB, which uses Auto Layout (as all of the views, buttons etc. do) and has constraints set up.
The constraints are made in IB excluding a single constraint being made in the WindowController. This constraint attaches the view of the tabView to it's superview with a visual constraint in the form of #"H:|[viewInsideTheTabView]| and #"V:|[viewInsideTheTabView]|. Next to that constraint, no constraints are being made or added programmatically.
With this context, I run and test my app only to see the following error appear after resizing the window several times.
The error:
*** Assertion failure in -[_NSDisplayOperationStack exitDisplayOperationForWindow:], /SourceCache/AppKit/AppKit-1138.51/AppKit.subproj/NSDisplayOperationStack.m:343
Exception _NSDisplayOperationStack underflow raised during heart beat. Ignoring....
When this exception is raised, the app freezes and does not become responsive again. I already checked every single button, view etc. for concurrent drawing, but none are (at least that is what IB tells me).
Is there anyone who encountered the same error and knows how to respond to it?
Thanks in advance.
Take a look at my answer within the tread you're referring to, it might be of use... My problems also only occurred in OSX 10.7, not OSX 10.8.
I tried using the same app (and resizing several times) on OSX 10.8 and it never crashes. It seems to me that Apple fixed a lot of (including this one) constraint problems on 10.8.
This makes it looks, to me at least, that 10.7 is like a test-case for their constraints. And to add some grounds for that comment; most of the methods used for animating constraints are available on 10.8 and later.
Still; if someone can counter this answer, please do!

Resources