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.
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 have an NSTextView inside NSScrollView/NSClipView, the usual setup. When I magnify the scroll view with [NSScrollView setMagnification:...] and resize the window, the width of text view's frame gets constantly larger, regardless of whether I stretch or shrink the window.
If the scroll view is not magnified, text view behaves normally. I have tried removing constraints and disabled subview autoresizing, but nothing helps. Whenever i set any sort of magnification, text view size changes on every call to resize. If the magnification is under 1, it shrinks.
Any bugs in TextContainer shouldn't make it wider either, as I've set textContainer.widthTracksTextView = false;
I am trying to keep the textContainer centered in my NSTextView by setting insets to it, but it gets impossible with the varying sizes. I've gone through my code and nothing should make it resize. Is this a bug or does the setMagnify: cause problems with constraints or some other math in LayoutManager?
For anyone trying to figure this out:
This is caused by a minimum width constraint for the magnified view, or any of its subviews. Seems like a bug, as I can't wrap my head around how this would be intended behaviour.
Just remove the >= constraint and do something to limit the size in run-time if needed.
I was wondering if anyone knew why IB has inexplicable high lighted areas on the odd nib here and there..
Below is an example:
What I mean is that light area within the area I marked out in red...
There's no views below the split view, there's no bounds which correspond to it and so far there's nothing complaining about "misplaced views" etc... What is it?
update: recently I worked out when it last happened that that weird "area" is always the same size as the rightmost NSView (whether its embedded in a NSSplitView or just 2 NSViews side by side.
Many thanks
Adrian S
It's due to a bug in XCode Interface Builder. And in my experiments it's been predictable according to the following explanation:
The lighter colored area is intended to highlight the container view of the current selection. So it you have an NSTextField within an NSBox, and you select the text field, the box will be highlighted. It's purpose is to dim out everything outside the scope that you can currently make constraints in.
You can see that it's a dimming down of everything outside the box, as if nothing is selected, the whole IB view port is displayed in the lighter shade.
The bug is that when you make a selection, IB clips the area of the container view to what's currently visible, and then adds this highlight as a rounded box 8 pixels larger. But when you scroll or resize the IB viewport, this clipped area isn't updated. So the rounded highlight box is seen to not cover the whole of the container view, just a clipped part (plus 8 pixels) of it.
I have a window I'm setting up with auto layout. There is a view in the middle of the window that contains three controls, and I would like the window to refuse to resize horizontally smaller than the intrinsic size of those three controls.
The outer buttons both have horizontal space constraints to "stick" them to the outside of their superview, and the checkbox in the middle has a horizontal space constraint sticking it to the left side of the "Sync text" button. There is also a >= constraint between the "Sync outline" button and the checkbox, to make sure they don't overlap, but the checkbox prefers to hang to the right. All these constraints have a priority of 1000. The window itself has no minimum size specified.
When I use the "Simulate Document" command in Xcode, everything works as I'd expect, and the window won't let you size it smaller than in the screenshot above. However, when I run my application, the window does allow resizing smaller than that width, so that the buttons start to shrink and eventually the controls overlap each other. I'm not implementing any of the size related window delegate methods, so I don't see any place in the app's code where it might be influencing the resizing.
Any ideas on what could be causing this difference in behavior?
OK, I finally figured out what the heck was going on here. It turns out the problem was that I was implementing the -splitView:constraintMinCoordinate:ofSubviewAt: delegate method (as well as the maxCoordinate one) to restrict the size of the split subviews in the vertical direction. Yes, restricting the vertical resizing of the split view affected the horizontal layout of the buttons.
It appears that what happens is that, if you implement those delegate methods, NSSplitView reverts back to using autoresizing masks to layout the subviews rather than auto layout constraints. Since the view containing those buttons is no longer participating in auto layout, the buttons smush together when you resize the window small. In the simulator, the split view doesn't have a delegate set, so all the auto layout stuff works fine in that environment. Note that merely having the methods implemented is enough to trigger this, even if they just return the proposed coordinates unchanged.
The solution ended up being quite easy, which was to delete the delegate methods and replace it with a vertical constraint on the subview to restrict its size instead.
After much reading and experimenting, I still cannot get a simple TextView to resize fully in the horizontal direction using Xcode 5.0.2 in Mavericks. It resizes partially as the window is resized, then stops with long lines wrapped around even though my containing NSScrollView continues to resize as expected (it has four default constraints and no horizontal scroller).
Can anyone point me to a simple code/IB+AutoLayout example, preferably just a window containing just an NSTextView dragged in from the IB template library --- one that works? The Apple TextEdit sample code is almost irrelevant for this purpose although it does resize horizontally quite well. Also, there is the clip view for which I can find little information.
Any other tips appreciated.
Thanks.
Answering my own question:
Turns out that my problem had nothing to do with AutoLayout and little to do with NSTextView. It was the textfile I was using to test my code! This file was composed of records with tab-delimited fields.
Turns out that NSTextView comes with a default NSParagraphStyle with predefined tab stops that end at character 56 whereas my test file had tabs beyond that. Therefore, my lines wrapped around at the last defined tab no matter how much I stretched the window.
After changing my search terms, I found what I needed at the following links:
Premature line wrapping in NSTextView when tabs are used
How to have unlimited tab stops in a NSTextView with disabled text wrap
Apologies for wasting bandwidth.
Not sure why such a simple thing does not work in your case, but nevertheless here's what I did in Xcode to get an NSTextView follow window resize:
Create a new project (not document based in my case but it doesn't really make a difference)
Drag a NSTextView from the palette to your window. Align all four edges with the window edges.
Open the "Add constraints" pop-up (second button from the segmented control on the bottom-right part of your IB view.
Each of the four spacing constraints should show a number equal to the distance of your text view from the container window. If you aligned them, this number should be either 0 or -1. Click the down arrow for each of them and select "Use Current Canvas Value". Do it for all four. Make sure no other constraints are selected.
Click on "Add constraints" on the bottom of the panel.
Run your project. Your textview should resize with the window.
Also, as Jay's comment mentions, make sure you do not have any "leftover" constraints in your view. You can check this either by observing Xcode's warnings, or manually by inspecting your view's constraints by going to the Size Inspector tab (4th tab on the Utilities bar).
If you need to have your textview arranged in a more complex layout, it might be worth taking a look at the AutoLayout Guide.