Here's the scenario:
I have a segmented control that toggles between hiding/displaying two views that each embed a view controller (via use of the interface builder's provided "Container View"). For simplicity's sake, in each embedded view controller I have a single subview with fixed leading and trailing spacing to its superview's margins along with fixed top and bottom vertical spacing between the subview and its superview's top and bottom layout guides. If the superview (i.e. the embedded View Controller) is a fixed width and height, these constraints should fulfill the x-position, width, y-position, and height requirements (respectively).
Here's the problem:
I want to add a height constraint to the subview. If instead of embedding a view controller in the container view I had just placed the subview (with the added height constraint) inside a container view (that didn't have a fixed height constraint), the container view would be automatically resized to fit its subview. However, because the container view embeds a view controller, auto-layout doesn't consider the constraints set between View Controllers.
In other words, I want the "Container View" (or the embedded View Controller) to be resized in height according to the subview's height constraint.
Here's the type of solution that I'm looking for:
Ideally, I would like the solution to this problem to be as clean as possible, which in my eyes means:
1) Sticking with the interface builder and storyboarding.
2) IBOutlets for NSLayoutConstraints.
3) Subclassing if need be.
However, any working solution besides the one that I proposed (which was to not embed a View Controller) would help me out.
Related
Similar question: How to resize a parent view based on the size of subviews layouted with Autolayout
I got an NSStackView which loads DisclosureViewControllers (NSViewController subclasses) just like in the Apple Example InfoBarStackView.
Those can expand and retract views of arbitrary height.
I would like the parent view containing the NSStackView to resize its height according to the contents of the NSStackView. In the Apple example that works.
However, unfortunately, Apple is resizing a NSWindow and I am using a CCNStatusItem (CCNStatusItem Github), a view that attaches to the status item in the Apple menu bar. That window resizes to the contents of the NSStackView when it loads, but doesn't resize when the contents change.
When I expand a section, the content overflows and gets clipped on the bottom edge of the view.
I went through all the constraints and tried to reproduce it exactly, but couldn't get it to work. In the Apple example, they are adding everything programmatically, whereas I added a NSStackView in Interface Builder.
Here are the constraints of the NSStackView:
My question would be: What constraints do I have in the Interface Builder (with what priorities), so that the parent view (the window) resizes with the contents of the stack view dynamically?
Do I have to call some method of the view to make it work?
Please let me know if I missed to provide some necessary information.
UPDATE
The accepted answer was the right way to do it. Here's the result. My forked version of CCNStatusItem can be found at https://github.com/julianvogels/CCNStatusItem.git
When using auto layout constraints, you don't need to call a view method to cause this effect, but just make sure that:
the views inside the stack view have constraints that will cause them to grow
the container has constraints to the stack view that indicate the container should grow with the stack view
the container doesn't have any constraints that would prevent it from growing
The screenshots seem to indicate it's not the first -- the views are growing as expected. So it could be either the second or third. The screenshot from interface builder seems to show that the bottom StackView<>Container constraint is optional (it's dashed). Depending on what the priority actually is, that could be your problem. Based on the design you described, there should be no reason for that constraint to be non-required.
The problem is that CCNStatusItem is not auto-layout-compatible. It sets the content view of its window to an instance of one of its own view classes (CCNStatusItemWindowBackgroundView). Your view is a subview of that view.
When it creates and adds its view, it does not turn off translatesAutoresizingMaskIntoConstraints or use constraints to position it relative to its superview. That basically means it can't be forced to a different size by constraints.
Likewise, when it adds your view to the background view, it does not turn off translatesAutoresizingMaskIntoConstraints on your view nor does it set up constraints to relate your view to the background view.
Since you've got the source, you can make those changes.
I know this question has been answered before, many times, but my use case seems to be just different enough from all of them that I can't quite figure it out.
My Problem
I have a scroll view that is not the same size as its superview. The scroll view has 1 subview that is the same size as it, but it needs to be able to be pinch-zoomed.
Attempted Tutorials:
(1) - Apple's Technical Note - This is done only with code and the examples show only full screen scroll views.
(2) - Natasha The Robot's Article - This was a really well written article but I could not get it to work for me. I think it's due to the fact that her scroll view is full screen.
(3) - Happy Coding Blog Article - Another full screen scroll view
... and lots other tutorials that were very similar to these
My requirements
My scroll view needs to be full width
My scroll view needs to be 40pt from the top and have a 1:1 aspect ratio
My scroll view needs to have one subview that is the exact same size of it but can be pinch-zoomed (aka content size = scroll view size)
I don't think that the size of the scroll view should impact anything, but it appears to.
What I have tried
As all the tutorials above recommended, I have only a single subview of the scroll view and have aptly named it "Content View".
View Controller
|-View
|-ScrollView
|-ContentView
|-ZoomableView
Here is a picture of my constraints:
As you can see, I have an equal width set up from the "Grid" (Zoomable view) to the view controller's view. I've also tried adding an equal width of the content view and the VC's view.
My question
I know I can get this to work with an explicit width and height, but I know I should be able to get it by setting the width equal to the view's width and height equal to the view's width as well (AKA 1:1 aspect ratio). How can I achieve this?
I think I ran into the same problem in the past. What I end up doing was adding a "container" view and use it to set up my width and height equality constraints instead of the view controller's view.
This setup will produce what you want I think: a scrollview with 1 subview that can be pinch-zoomed in the view controller's view (grey in the screenshot) but with a top margin of 40pt.
I have a UIScrollView with a UIView as a subview. The UIView has a bunch of data entry fields arranged vertically - essentially just a fixed format data entry Form.
I want to keep the UIView's vertical size and adjust its horizontal size to match the size of the UIScrollView which changes depending on the orientation of the device. Note that this is all placed in the Detail view of a UISplitViewController.
So the user will have to scroll vertically but not horizontally as all the text fields on the UIView should resize themselves to fit horizontally on the screen.
Currently if I resize the UIView by changing the frame width to match the UIScrollView's frame width then the UIView subviews (the text fields) don't resize themselves according to the constraints setup in IB. The UIView just seems to get clipped. There is no horizontal scrolling so this aspect is working correctly.
I have autoresize subviews set on UIView and on UIScrollView.
Any tips on what to do here ? Also where would I put code to resize the UIView if the device orientation changes ?
Additional information.
I created the UIView in IB as a separate view in the same NIB as the DetailViewController containing the UIScrollView. Because it is much taller than the UIScrollView the only way I can find for creating it in IB is if I set it up as a separate view of the desired width and height. I then create an IBOutlet and add this view as a subview to UIScrollView in the viewDidLoad method. This all seems to work find with the views all displaying correctly, with the exception that the UIView subviews are not resized horizontally.
Any suggestions on what I may be doing wrong here?
Since you are using not putting the view inside scrollview directly from the xib, the IB doesn't provide the options to give constraints that has anything to do with superview. You might have to add the constraints programatically.See here.
EDIT:
Also try using the below on the view (haven't tried, should work according to documentation, but not sure with auto-layout):
self.view.autoresizesSubviews = YES;
Or if you don't want to use auto layout at all then the earlier method of setting the view to expand (horizontal/vertical) in the size inspector would do. For this you have to disable auto-layout. Select xib-> File Inspector -> Uncheck auto-layout checkbox
OK after more discovery I think I have found the right way to do what I am trying to do so i thought I should leave a note regarding this. Remember I am trying to create a scrollable form that resizes its width but not its height so the user only has to scroll up and down to access fields.
To create a large fixed size form that requires scrolling on the device make sure you set the ViewController size to Freeform in IB. Then you can create the view to be whatever size you want in IB and at runtime it will resize to the devices size.
Place the UIScrollView (I call it the scrollView) in the main view and pin it left and right and top and bottom (i.e set constraints using IB)
Place a UIView (I call it the contentView) in scrollView and make it the same size as the scrollView and also pin it on all sides to its superview (the scrollView)
Now add all the labels and text fields are required to the contentView and make sure you add vertical constraints from top to bottom and left to right so that autolayout can figure out the width and height in order to calculate the scrollView.contentSize
Set the contentView width constraint as a fixed size to make it look reasonable in IB. Bear in mind we want the width of contentView to always match the scrollView width so the user does not have to scroll sideways, only up and down. We will set the proper width in code at runtime as I have not found any way of doing this in IB only. Perhaps setting priorities on constraints might achieve this but I think UIScrollView won't do this for you.
Now add a property the ViewController.h file and connect this to the contentView width constrain you created in 5) above.
#property (weak, nonatomic) IBOutlet NSLayoutConstraint *contentViewWidth;
Finally create a viewDidLayoutSubviews method in ViewController and add the following code to set the contentView width to be the same as the scrollView width.
- (void)viewDidLayoutSubviews
{
self.contentViewWidth.constant = self.scrollView.frame.size.width;
[self.view layoutSubviews];
}
If things don't resize properly check all your constraints are correctly set. IB seems to do some things that seem strange to me. But finally I have it working with what appears to be minimum coding.
You can also resize vertically in the same way as long as you set the constraint priority on subviews in contentView to be lower than 1,000. Also set a greater than or equal to size with a high priority if you don't want it smaller than a certain size.
If anyone can figure out how to set the contentView such that it resizes its width to match the scrollView using only IB constraints I would love to know how.
I have an iPad app using Storyboards. I have one scene with a UIView, which has an additional UIView on the top half (which I draw on), and a UIScrollView on the bottom half (I needed to keeep them separate). I'm having a hard time figuring out how to address the UIView with this code that I copied from another SO question:
CGFloat scrollViewHeight = 0.0f;
for (UIView* view in scrollView.subviews)
{
scrollViewHeight += view.frame.size.height;
}
[scrollView setContentSize:(CGSizeMake(320, scrollViewHeight))];
The way I read the code above, I'm supposed to use the UIView, but that doesn't make sense, since the UIView covers the entire "scene/window". It makes more sense to me to use the UIScrollView to calculate the ContentSize.
So, what am I supposed to use?
Not completely clear on what you are asking. Once you have a reference to the scroll view, either through tags, properties or some other method, you should set its content size to the width and height of all of its content combined (accounting for overlap, etc). Ex. if you had a single image view that was 600 by 900 points inside the scroll view, you'd set its size to a 600 by 900 CGSize.
That goes through all of the subviews of the scroll view using a for...in loop (aka fast enumeration), adding their heights together, then uses that as the height of the content. I don't think that would be a good way to do it, because that assumes that all the subviews are stacked vertically on top of one another perfectly. It's basically going, "For every subview of my scroll view, add their height to this total and then use that as the content size's height."
The easiest way to manage scroll views is to slap all the content into one UIView, place that in the scroll view, then set the scroll view's content size to the frame of the UIView. If you need a reference to the UIView contained in the scroll view, you can set it to a property or give it a tag and use viewWithTag.
Is there a way to get the height of the content in an NSTableView. In iOS, you can use the -contentSize method of UIScrollView. However, the -contentSize method of NSScrollView seems to just return the height of only the visible section of the NSScrollView, not including whatever is offscreen.
So, how can this be done on a Mac?
- (NSSize)contentSize in Appkit returns the size of the NSClipView, and not the height of the content that scrolls inside the table view. I don't know how UIScrollViews work, but on OS X, an NSScrollView has a "content view" (more aptly named the NSClipView) that clips the actual content, which is provided by a document view (scrollable if it has a size larger than that of the clip view) that is a subview of the clip view.
As a side note, the NSScrollView scrolls by setting the document view's bounds origin (to the best of my knowledge).
It looks like what you want is the height of the document view, the height of the actual content. For that, try something like
scrollView.documentView.frame.size.height
You can get the real content height of NSTableView by
Objective-C version:
tableView.intrinsicContentSize.height
Swift version: tableView.intrinsicContentSize.height