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.)
Related
To keep things simple, let's say I have a window containing a single view, which has auto layout constraints binding all 4 sides to the window container view with offset 0. And assume that this view also has a constraint setting its aspect ratio to a constant value. If I resize the window manually, then then window nicely maintains the desired aspect ratio. But if I click the little green zoom widget, then the window fills up the whole screen, regardless of the aspect ratio, with part of the view being above the top of the screen. Is there some way I can make zooming resize the window as big as it can be, without violating auto layout constraints?
I couldn't very well detect this problem in the delegate method windowWillResize:toSize:, because that doesn't tell me which screen it's thinking about putting the window on. I could try to fix the window size in the windowDidResize: delegate method, at which time I do know what screen it's on, but I'm not sure exactly how to do that without reinventing Auto Layout's wheel.
Apparently someone thinks I wasn't explicit enough, so I'll try again. Steps to reproduce:
In Xcode, create a new macOS App project using XIB interface.
Open MainMenu.xib and select the window.
Reshape the window to be approximately square.
Using the Attribute Inspector, set the Full Screen behavior for the window to Auxiliary Window.
Drag an Image View from the library and drop it in the window.
In the Attributes Inspector, set the image view to show the NSComputer image and scale axes independently.
Expand the image view to fill up the window content area.
With the image view selected, click the button to add new layout constraints.
Add 5 constraints, binding the 4 sides to the container, and setting the aspect ratio. (see screen shot)
Build and Run.
Observe that if you resize the window by dragging an edge or corner, the aspect ratio remains fixed.
Click the green zoom widget in the title bar of the window, and observe that the window expands without regard for the aspect ratio constraint, cutting off part of the image.
I just set up a test project exactly as you specified, and when I invoke the window zoom widget, the window expands and retains its aspect ratio i.e. it works as expected. The only thing I can think of that might be causing your issue: maybe your content hugging and content compression resistance priorities are at odds with your constraints? Mind you, I just left them at the default values and it worked fine. Unfortunately Mac/AppKit development (esp. when using IB) is rife with these kind of odd bugs and weird behaviour, probably because Apple has not given it any love in years, so bugs creep in/fester and they are clearly so DONE with developing UI the 'old fashioned way'. (Using SwiftUI to make a Mac app is just as frustrating, in different ways, so I'll stick with what I know). FYI, I used Xcode 13.4.1 to create this test project. Good luck!
I have a window with a textview in a scrollview and two buttons. I have added constraints at all sides, leading, trailing, top, and bottom. For the buttons I have fixed width and height, and distance to bottom and edge.
I want it to look something like this:
And this is what Interface Builder keeps giving me:
It also keeps offering to fix ambiguities by adding missing constraints, but actually clicking the button has no effect. No constraints are added. The error (and the offer to fix it) remains.
I've tried added the constraints it is asking for, although I can't see why they would be needed and at least the buttons already have (fixed) width constraints. But I keep getting errors and the window keeps getting shrunk to nothing.
When actually running the program, the window looks fine. But I suspect these autolayout errors have something to do with this problem: NSTextView in magnified NSScrollView breaks on resize
The project is here: https://github.com/angstsmurf/spatterlight/tree/helpviewtest
(The branch helpviewtest is a cut down test case created specifically for this problem.)
You have a Text view embedded in a Clip view embedded in a Scroll view, none of which have an intrinsic content size.
IB has no idea what's going to go on at run-time.
So, while everything looks great when you run this, your code will have supplied enough information to lay things out as desired.
To get it to "look right" in IB (and avoid the errors/warnings), you can give the ScrollView a Placeholder Intrinsic Content Size:
Question: Can someone identify why I am getting the extra grey area shown in my add item (top screen in screenshot) and how to eliminate it?
I have tried manually setting the size of the background object, removing and re adding constraints, clicking all the Xcode generated solutions for handling the autolayout errors shown below, setting the presentation setting to full size ala this answer all to no avail; it refuses to be consistent with the main menu screen (bottom)
Context:
Running Xcode 11...I have two scenes in a generic barcoding app, the main menu and the add item scene, and I am designing with iPad's in mind. With the size class for ipad pro 9 (wR hR) and set to landscape orientation, my add item scene has a huge amount of gray area bordering the visible content, unlike the main scene (though there is also a little grey area in portrait)
Figured out what was causing my problem; was using the wrong form of segue between screens, per this answer, in my case, a modal segue when I should have just been doing a show segue. Deleting and adding show segues with the presentation set to Full Screen in the destination views Attributes inspector did the trick.
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.
Here is my IB setup:
http://img145.imageshack.us/img145/5929/picture1gxr.png
When both NSScrollView and NSTableView are set to autoresize and autofill (all the arrows in the Autosizing section are checked) my window does not resize. Actually it resizes, but by a pixel, as if it remembers that it is not supposed to resize after I start dragging the corner. If I uncheck the autofill arrows (disabling NSViewWidthSizable and NSViewHeightSizable) on the NSScrollView, the window resizes fine, but of course, the scroll view does not resize with it.
The weird thing is that in the situation where the window is "rigid" if I resize one of the NSTableView's columns beyond the view (thus causing a horizontal scroll bar to appear), I can resize the window but only until it reaches the size big enough to accommodate all the columns and then becomes rigid again.
Maybe you have set a fixed minimum/maximum size for the window?
Is this a feature or bug of BWSplitView? What if you make it an NSSplitView?
If it turns out to be a bug, you should report it.
Ah, I've reverted to my last good commit and rebuilt the view hierarchy and everything worked. It is probably a bug in BWSplitView, but I can't reproduce it anymore, so can't report really.