In Xcode 9, an NSPopUpButton is now issuing a warning about 'View is clipping its content'.
The only satisfying settings seems to be to stretch it horizontally through the view (right and left fixed constraints).
This issue is from a clean project with just this popup button added to the Storyboard. In other words, can be recreated easily.
The constraints are top-left simple fixed to superview with the added (since Xcode 9) right 'greater or equal' to superview with constant as 'standard'.
Also, the warning is not a 'yellow' warning. It only shows when opening the 'Issue Navigator' (⌘5).
I'm assuming of course, that popup buttons are not required to grab the whole view length now.
You just need to increase your control size because its contents (NSMenu items which belong to it) are too big to fit inside the NSPopUpButton control.
Your case when you stretched the control to the end of the window satisfied that condition and your control became big enough to contain its contents.
Related
I have a view controller that's fixed size (it can not be resized). This specific view controller is presented as a sheet in a window, I disabled the resizing by setting preferredContentSize. Since it can't be resized anymore, I left the view without any constraint. However, when I build the app, I got a lot of warnings that says :
Views without any layout constraints may clip their content or overlap other views.
I do know that if you don't add any constraints in a standard window it will clip when it is resized. However, resizing is disabled on my specific window so that I know it won't happen. Is there a way to silence this warning? There are a lot of views on this specific view controller and it's blocking other useful warnings that I may encounter in the issues navigator.
This view controller is presented through a "Sheet" segue.
I had a single warning saying the same thing.
Editor > Resolve Auto Layout Issues > Add Missing Constraints
worked for me.
If it doesn't for you, something else under "Resolve Auto Layout Issues" might work.
For me what worked was the reposition the elements: Drag them again into position and drag their height and width to the desired size again. Then click on "Resolve Auto Layout Issues" and click on "Reset to Suggested Constraints".
Since no one answered this, here is how I fixed it. For each view on the form change the Layout option from Automatic to "Translates Mask Into Contraints". If you want it anchored to the upper left corner, select the top an left red handles and leave the lower and right unchecked.
For me what worked was; select the last element that cause the warning
size inspector tab > layout > Autoresizing Mask
I'm trying to make a divider, so what I do is:
1) Make a new View
2) Change the background to the color I want the divider to be
3) Control click and center it horizontally on a label on top of it
4) Compile, my view is gone.
5) Remove constraints, compile, my view is there.
6) Add left and right constraint for autosize, compile, view is gone.
It also states that the height of my view is ambiguous.
How can the view be gone by merely constraining it?
Screenshot:
Your view does not disappear. It just getting zero size.
When you remove constraints it won't iOS won't layout your view that is why it's size not changing.
And in you last case with leading/trailing constrains your view will calculate its width depending on it's superview width, but since system can't calculate height it gonna change it to zero.
Other views and like labels and images have content and with a help of defined intrinsic content size they system won't resize them to zero sizes but to their content size.
here is my output I tried in swift using Xcode and tried setting constraints as I do
I'm trying to implement a counter view that shows items count in NSTableCellView.
The weird thing is it gets moved to right automatically after resizing window or scrolling the NSOutlineView which has the NSTableCellView.
Here is some screenshots of it. You will be able to see the counter view which shows "42" being moved to right after resize the window.
Following is the init state of the counter view.
Following is the state after resize window.
Following is difference between init position and the position after resize window.
Cell Autoresize Property
Count Button Autoresize Property
I'm guessing this is related to scrollview but I was not able to find more clues about this issue. BTW, official Mail App on Mac works as same with this but the difference is the counter of the Mail app is being changed right after launch so it does not being moved after resize window.
Anybody knows about this? Any thoughts would be appreciated.
Here is a link that allows you to download the sample project that apple provides and you can reproduce what I'm facing.
Sidebar Demo App that providing by Apple.
You just need to change Deployment target before you run it from Project -> Targets -> Deployment Info section.
If I interpret the autoresizing screenshots correctly, the '42' control is behaving as specified. You've pinned the right side of the '42' counter to right side of the cell. And that is where it stays, glued to the right side of the cell.
The cell is pinned to the left side of the tableview and that is where it stays, glued to the left side of the tableview. You have not pinned the right side of the cell to anything and so when you resize, the right side goes where it pleases, only maintaining the specified width of the cell. If you want to glue the right side of the cell to the width of the tableView or column (not sure which it is), pin it. Do specify a minimum width for the cell. If you don't specify a maximum width, or fixed width, the cell will stretch and shrink with resizing. If you fix the width, only the right view or column will stretch.
I have an OS X app originally built using Xcode 4, now using Xcode 7. When "springs-and-struts" was superseded by constraints, I reworked the UI to use constraints. Simple enough, and seemed to work well.
Fast forward two years after first release, and for the second release I needed to add controls and increase the height of the main app view. Unfortunately, my test team is using smaller screens and cannot see the whole view. They need to resize vertically.
Problem - even though the resize controls box is checked, the window cannot be resized. The controls do not show at run time. I tried
Setting lower minimum window content size height, but that did not change anything.
Changing content compression resistance did not change anything.
I am thinking this issue has something to do with constraints.... Any ideas on how to get resize to work?
Edit: After playing with a new test app some, I am more certain the problem is due to constraints. I have a control where I have constrained leading and trailing space to superview and width - there went horizontal resize.
I really need to have a view where the user can resize the window, but scroll the content. However, in this case, the content is other controls. I think on iOS, I would use a UIScrollView. On OS X, I have tried a scroll view control and have tried embedding in a scroll view, and neither have the desired effect.
I had the same issue and solved it by adding a view to be used as a "container" in the view controller.
Pin the top left corner of the "container view" to the view controller (leading space 0 and top space 0). Add equal width and height constraints on the "container view" to the view controller. Then move all your objects into the "container view" and add your object constraints on the "container view" not the view controller.
In my case, it happened in this way (Xcode 13.1).
I mistakenly added a view from IB outside of the window view hierarchy. The new view was added as a separated object (a top node in the interface builder file). I added the new view into the window by drag-n-drop.
I found the new view had different behaviours, for example, I couldn't set the top space constraint. With this view in the view hierarchy, I couldn't change the window size (content view size) at all.
I removed the view and added another in the view hierarchy, it worked as normal.
I think IB initialises the view differently if it is a separated object (top node of the interface builder file).
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.