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!
Related
Recently, I encountered a problem with the Interface Builder which I failed to solve. I'm using a UICollectionViewController and whenever I add a Cell it immediately shows a orange rectangle (indicating a auto-layout update). Updating the frame/cell doesn't change anything. The warning associated with the orange marking reads "Expected: height=Y, Actual: height=X" where Y is always exactly X-100. That is: When I set a custom cell height of 193, it says "Expected: height=93". This happens no matter which size I enter.
The problem with this is that I have many difficulties with the subviews and their constraints. For instance, if I add a subview with the constraint to keep the same height as the cell, it will be shown as 93 (the expected height), even though my cell should be 193. Layouting becomes impossible.
I tried adding a new cell, same issue. I tried removing every subview and re-adding them, nothing.
Any ideas are highly welcome.
Thank you very much!
Solution found ! (Xcode 9.2)
The bug seems to only happen when you try to embed the UICollectionViewController in a Container View in the storyboard. The workaround is to remove the segue while you set your constraints, and re-add the segue once your constraints are well set.
I also think that setting UICollectionViewController size as Freeform could be responsible of the bug. If so, try to set constraints before changing the size.
Hope this helps !
I'm not sure if this solved it, but the warning and issue disappeared once I did the following:
Select the CollectionViewController in Interface Builder and set the size to freeform and make the height larger, large enough to show all your template cells. (Plus: maybe refresh the views). That solved the issue for me.
In my case, I have added two collection view cell, withing collection view Controller.Only setting the view controller to free form wont help us. Need to update the size, to get rid of the warning.
updating collection view cell frames, wont help us. Warning will be continuously changing its length.
I tried to work without considering the warning, as I have set my collection view cell size programmatically and it does working as expected.
I think it's just a strange bug
I delete the collectionViewController in SB, then create a new one, the problem disappear
This is a common bug with Interface Builder. I don't know the exact cause, but I believe it's something to do with placing collection views inside arrangement views that do not have an exact size. I've seen it when putting them in scroll views, stack views and container views.
There is a simple fix, although I believe this to be a bug in IB that ought to be corrected by Apple rather than hacking around it. The solution (for me at least - your mileage may vary!) is to place the collection view inside an ordinary UIView and pin its edges to it, then place that parent view in the position that you wanted your collection view with all the constraints it required.
I usually found that there were actually no auto layout issues at run-time, which is why I believe this to be purely an Interface Builder bug.
I'm updating an existing project which has worked fine for years to High Sierra. The view loads correctly and looks as it always has:
Then, after I open a popup and close it again, the view moves things around, flips things, and generally looks very crazy:
Notice the Info title drops to the bottom, the left side text items reverse order, and the date and dropdown text flip. Mouse interaction seems very scrambled as well when this happens.
I'm not sure where to even start with solving this one, anyone have any ideas?
This is using xcode 9 beta 5 and High Sierra Beta 6.
Update: This is also in xcode 9 GM and High Sierra GM Seed
Update
I have determined this happens when I call reloadData on the NSTableView that this view is within. So the question now seems to be how to refresh the table data without it going wonky.
It seems that reloadData and also reloadDataForRowIndexes:columnIndexes: both produce odd behavior in High Sierra. My way around this is as follows:
-(void)refreshAllCells {
NSMutableIndexSet* rowIndexes = [[NSMutableIndexSet alloc] init];
if (self.myTable.numberOfRows != 0)
[rowIndexes addIndexesInRange:NSMakeRange(0, (self.myTable.numberOfRows))];
[self.myTable removeRowsAtIndexes:rowIndexes withAnimation:NO];
[self.myTable insertRowsAtIndexes:rowIndexes withAnimation:NO];
}
If there is a better answer I would still love to see it.
For me, adding wantsUpdateLayer in my subclass fixed the problem.
override open var wantsUpdateLayer: Bool {
return true
}
In IB, tick the checkbox to use CALayers on your tableView's views. I toggled them on for all the view's in the tableView view hierarchy and all the flipping stopped!
Can't post an image as I don't have enough reputation but this link shows the IB checkbox:
I've encountered this bug as well and while implementing another answer I found the real reason for the bug due to an exception that now got raised:
In my case, reloadData was called again while reloadData was still being executed. This caused the rendering issues.
The "loop" was happening as a side-effect of calling tableView.makeView(withIdentifier: identifier, owner: self) in tableView(_:, viewFor:, row:). The owner: self caused awakeFromNib() of the controller getting called again which in turn triggered the reloadData(). In my setup, I was not (yet) using separate XIBs for the table cells but was using the cells that were setup inside the table view as visible Interface Builder.
So the solution was to change tableView.makeView(withIdentifier: identifier, owner: self) to tableView.makeView(withIdentifier: identifier, owner: nil) and also use separate XIBs for the table cells.
I'm seeing this as well in 10.13, when 10.12 had worked just fine. I was able to work around this problem by, oddly enough, re-adding the cell view's subviews in its [layout]:
- (void)layout{
if([self needsLayout]){
for(NSView* v in [[self subviews] copy]){
[self addSubview:v];
}
}
[super layout];
}
I experienced this as well. Further testing revealed that the contents were being drawn WHILE the tableview Data source was being updated. By eliminating a spurious update, I was able to eliminate the issue.
I reload the data in the draw method, however I have moved the data update code outside of that method. Not sure if this helps the OP, but it worked for me.
All of a sudden I received several mails from customers who complained about all table texts being shown vertically flipped. All of them use macOS Mojave.
After a lot of hacking, and trying the solutions detailed above (to no avail alas), I decided to disable the autoSave property of the NSTableView:
//Swift.print("Now setting autosaveName of primaryView to \(self.className).primary")
//primaryTableView.autosaveName = "\(self.className).primary"
//primaryTableView.autosaveTableColumns = true
Then the problem was instantly gone. But now my customers weren't able anymore to change and save the column widths and order. So, instead of doing it programatically with tableView.autosaveName = "autosavename"; I now set up the autoSave property in the Table view properties, and also checked 'Column information' in the Attributes Inspector (while showing xib file). And then it works just fine..
I use the currently latest version of Xcode (10.1 10B61), and the problems only surfaced when using macOS Mojava 10.14.0 - 10.14.2 . High Sierra and Sierra gave no trouble. Whether I compiled the project in High Sierra or Mojave made no difference.
So, I hope this helps for other people confronted with this bizarre problem. I think it's a bug in macOS Mojave.
Had the same problem, reproducible on High Sierra and Mojave. The issue was with NSOutlineView autosaveName, other solutions didn't help. However I needed this feature.
Moving adding/reloading data to "viewDidAppear()" instead of "viewDidLoad()" solved the problem.
Edited:
It happens only when:
autosave is present
items get loaded on viewDidLoad before sorting is applied
the same list of items gets re-loaded after sorting is applied
all of the above happens on viewDidLoad
If you try to access tableView.sortingDescriptors (or NSOutlineView) - it automatically applies sorting. If it happens before loading the data - it works ok.
Loading data on viewDidAppear still looks like a better option.
I'm an intermediate iOS developer who's trying to jump on the OSX side of things.
I've been struggling to create an accordion-like display of several views, where only one view at a time can be unfolded to occupy the whole parent's view's available space. In other words, click on a view's title bar, it will both open/unfold this view and close/fold the currently open view, with animations'n'all. Oh end, I need the views' contents to be scrollable.
I tried starting from Apple's NSStackView sample code, but first it is not quite what I want, and what's more, I can't figure out how to start from here to end up where I eventually want to be.
Then I tried to master the Auto-Layout facilities but with no success. Truth be told, this whole Auto-Layout thing still confuses me some.
Does any of you have clues as to how I should proceed? Sample code? Tutorials (I tried several Auto-Layout tutorial but at the end of the day they still leave me missing the tricks I'd need to figure...).
Thanks.
/Julian
Check out the sample code: InfoBarStackView. It creates an accordion-like interface, the one difference from what you're describing is it lets multiple views be revealed at the same time (although, that's a simple difference).
It uses NSStackView and autolayout constraints to create the interface and drive the reveal/hide animations.
The stack view could also be put into an NSScrollView to allow the content to be scrollable. (Something similar was done during a WWDC 2013 Cocoa Animation talk).
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 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.