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).
Related
I'm trying to update my app for the new iPhone X. After reading about the safe area feature and the check box "Safe Area Relative Margins" in each UIObject's "Size Inspector" (ruler tab), I didn't think this would be too bad. However, that feature does not seem to be working for me.
Nothing changed for regular iPhones, which is good, however for the X, the top of my app overlaps the top inset of the phone by a third. Is there any known way to fix this* or something I'm missing?
*By fix this, I mean make it so that my objects start below the outcrop, like the second picture.
What is happening:
Desired Behavior (from https://arstechnica.com/gadgets/2017/11/how-devs-updated-their-apps-for-the-iphone-xs-screen-and-the-notch/):
I too have wasted hours on this. And while I cannot answer your question of why this is broken in Xcode, I can provide a solution.
But first let me note than in Xcode 11.3.1, I experience the same issue in a new project created from scratch.
Set up your storyboard:
On your storyboard, select "Use Safe Area Layout Guides". This will add a safe area to each of your ViewControllers. It will also require you to target iOS9+. You might be able to skip this step though (see step 4 below).
View your storyboard as iPhone 4s.
Fix each ViewController:
Select all views under the top-level view.
Click Editor | Embed In | View Without Inset. This creates a new view and puts all your views inside.
Make this new view expand to the safe area by adding safe area constraints (by control-dragging your new view onto the top level view).
Leading space to safe area
Top space to safe area
Trailing space to safe area
Bottom space to safe area
If you did not opt into using a safe area storyboard above, you may be able to create four equivalent constraints by using the Top Layout Guide, Bottom Layout Guide, and the left/right sides of the top-level view. This may not work in landscape though. And I did not test this.
Set your new view as transparent.
Give your new view a name like "SafeAreaView".
In iOS 11, margins are inset from the safe area. Thus, your zero top margin becomes a 20 top margin — explaining your screen shot. If that's not what you want, set the view's insetsLayoutMarginsFromSafeArea property to false.
In my case modalPresentationStyle = .fullScreen has to be set to the view controller being presented
I have this app that uses a NSSplitViewController as the root and has a NSTabViewController connected as its detailViewController.
This app is set to launch at 1024x768. The left pane should launch at 320x768 and the right pane (where the tabViewController is), should launch at 704x768.
From 10 times I run this app, 9 times it will launch with the incorrect size (about 500x500). Other strange thing is that this app should not be scalable, but if you hover the mouse near the window border you see cursor indication to scale.
I want this to launch at the correct size and have no scalable option.
Both of these settings are on interface builder but are being ignored.
You can download a sample project that demonstrates the problem, here. Stop and run the project several times to see the problem.
How do I solve this?
I couldn't say for sure what's causing the problem, but one way you may be able to solve it is to add some constraints. Interface Builder doesn't allow you to constrain the default NSView instances that it inserts into the left and right panels of the split view, so you'll need to add your own. The screen-shot below
is taken from your demo, but after I've done the following:
Added a subview to the left split (My Content View), and pinned it's edges to the edges of its superview (the view Xcode automatically adds to the splitview)
Added an explicit width constraint of 320 pixels to My Content View
When I load the app both splits are visible, the divider doesn't budge, and the window can't be resized.
Update - a better solution
Although constraints are one way to solve this problem, I think the root of the problem lies in a bit of unexpected behaviour in Interface Builder. When you drag an NSSplitViewController object onto the canvas, and make it the target of the window controller's content window relationship, the split-view controller's view outlet is not actually set. One consequence of this appears to be that, when you load the app, the divider will appear to be right over to one side. To resolve this, set the aforementioned view outlet to point at the split view:
I've created a demo project with a setup similar to that in the questioner's demo app.
For reference, the same problem occurs if the window content segue points to an NSTabViewController scene. New windows open with a size of 500x500.
I solved it by placing a plain view controller with a container view between my window and my main tab view controller. The window will then use the size of the container view as initial size.
Here is what I did in detail:
Added a new view controller scene to the storyboard
Made that view the size I want my window to use initially
Added a container view to the new view controller scene & added 4 constraints to have the container cover the view completely
Connected the window's content segue to the new view controller
Finally connect the container view to my actual tab view controller scene
Before:
[Window Controller Scene] → [Tab View Controller]
After:
[Window Controller Scene] → [View Controller Scene] → [Tab View Controller]
(with Container View)
Occasionally in my iPad Master/Detail app the Master View slides into view at a full-screen width rather than its usual 320p width. This happens under ios 5 and 6 on iPads 1 and 2. When it happens the view functions normally and the Master view continually reappears at full screen width until the app is restarted. Table view cells are also stretched to full-screen and so they look strange. I have not been able to characterize this except that it may happen only after I have received a memory warning.
There is no place in my code where I try to change the width (or anything else) of the Master view. Has this been seen or reported? I've found no mention of it in my searches. Thx
Do you use Interface Builder to create the views? If so try modifying "Autoresize subviews" attribute in the "Attributes Inspector" of the view
I have quite a large storyboard with many views, a lot of them do not display at the correct size or even have a navigation bar. Is this some kind of bug in XCode?, because they all look fine when simulated or built to a device.
Thanks
I have faced it lot of time below solution works every time.
Try This One:
1. Select the StoryBoard you are facing problem
2. Goto Attributes Inspector -> Simulated Metrics -> Size -> There are four options(default is inferred)
3.Select or switch between options other then default(repeat it twice or more if needed) then resize your views and controls to fit your selected screen size.
According to me this happens because:
Sometimes inferred (size) behaves as if its an 3.5 retina screen but our storyboard size is retina 4 full screen or vice-versa
Best Practice to avoid such problems :
When you start working with storyboard first select appropriate size you want to work with (3.5 or 4 full screen) then only you should set your views or controls.
I had this issue when embedding Container Views into the same View Controller.
With three Container Views embedded I found that Xcode auto-sized two of them when I selected "Apply Retina X.X Form Factor" but the size of the third was left untouched.
Solution
In the parent View Controller the third Container Viewer was missing constraints. Adding those constraints got every thing straight. (I also had to size the Container View to fill its parent Controller Viewer)
This is a very simple step. After selecting View Controller, go into your Simulated Metrics and select size and place it on iPhone 4-inch and then select Orientation and place it to Portrait and there you have it. Your main storyboard metrics are fixed. Again this is very important to know that this will not mess up anything your height or width in your project
I have a 10.6 app that I am building on Lion with Xcode 4.3
There is a horizontal split view in the main view, containing the following:
The top view contains an NSSearchField with an NSTableView below it.
The bottom view contains a WebView.
I have it working, but when I resize the split view the top view behaves oddly.
What I want to happen is for the search field to remain where it is, the tableview to remain where it is, but to expand if the split view is dragged down. If dragged up, I want the webview to overwrite the search field and table view.
You can see what I mean in this clip: http://dl.dropbox.com/u/160638/Work/TENSOFT/resizemostlyokay.mov
This keeps the things in the right place when I drag up, but doesn't expand the table when I drag down. The view is expanded, but not the table.
So, I changed the autosizing constraint on the table view / scroll view to make it expand when the view is resized. This is what happens: http://dl.dropbox.com/u/160638/Work/TENSOFT/resizeproblem.mov
When the split bar is moved upwards the table view is moved upwards inside the top view until it overwrites the search field. It doesn't move back when the bar is moved back down.
I cannot find a way to make this work by changing the autosizing constraints. This is usually pretty easy stuff, so either I'm missing something obvious or...?
Has anyone seen this behaviour before when creating SL apps on Lion with Xcode 4.3?
FYI, if I replicate this in a new 10.7 project using auto-layout everything works fine.
Regards
Darren.
When you allow an NSSplitView to make one of its subviews very small so that the subviews effectively overlap you get layout issues and this is one of the reasons that Apple introduced auto-layout (watch the WWDC video about auto-layout and I think they demo this problem near the beginning).
If I were you I'd set a minimum size for the top pane so that, for example, it stops resizing when it is 100px high. You can then allow it to collapse so that the user can still show just the WebView.