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.
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 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'm experiencing a weird behavior in Interface Builder. I almost feel like it's a glitch, but I'm hoping that I'm just misunderstanding something, or that someone knows what weird AutoLayout behavior I'm experiencing, or something. I'll try to describe it as best I can...
I've got a ViewController in Interface Builder, with nothing but a UITextView. Nothing unusual about the TextView, I just dragged it in from the sidebar, and it's the first thing I added. But here's the thing: the text is offset by about 50 points. There's nothing in the Size Inspector that would explain it, the text is just spaced down. BUT, if I click and drag it around, the text pops back up to the top. Then I drop it in a new place, and the text is offset again.
Here's where it gets really weird: if I drag a UICollectionView into that same ViewController, it's fine (the default cell is right up in the top left corner), but as soon as I delete the TextView, the default cell gets moved 50 points down in the CollectionView! Now I have a CollectionView with an offset cell, and if I drag a new TextView back on, it's fine, but deleting the CollectionView adds the offset back to the new TextView! The location of the views is irrelevant (either at the time of adding or later), the older view will always be offset.
And, just for an extra dose of weird: whichever view is offset, if I click and drag it to move it around, the other view will be offset until I drop it in its new location. Oh, and deleting the ViewController entirely and starting again does nothing. The behavior remains.
What black magic is this?! This is the 8th ViewController I've added to my Storyboard (12th if you include abstract ViewControllers like TabBarControllers etc), and none of them had this issue. Why would this forced-offset exist, and how do I stop it? Is this some weird permutation of AutoLayout or something? Or does this sound like a genuine glitch, and I should post on a tech support forum?
EDIT: Just to be clear: the offset does appear when the app is run in the Simulator. IB shows that the frame isn't changing, the content is being offset within the frame, but whatever it is, it DOES show up in the final app.
The answer turned out to be turning off "Adjust Scroll View Insets" on the ViewController.
Sort of a weird behavior for the ViewController to present like that, adjusting a single ScrollView without any regard for its position or size, but at least it was an easy fix.
I'd like to make it easier for users to access the searchbar. Currently, the searchbar is above the tableview and when a user scrolls the tableview, the search bar scrolls off screen with it. Is there an easy way to position it above the tableview so it will always be visible?
I am using .xib files instead of the storyboard b/c I'd like my app to be compatible back to iOS 4.0.
Well what you could do is just place a search bar above the table view in your XIB. Or just move the search bar you've (presumably) got in your table view's header view at the moment and put it above the table. You'll also have to shrink the table by 44 pixels (the height of the search bar) and move it down so that the search bar is above it.
If you go for deleting the one in the table view's header view and creating a new one then just make sure you hook it up correctly to whatever it is that's currently using it (i.e. probably an outlet for the search bar and its delegate).
I'm currently working on a MonoTouch application with a NavigationController, a root view with some ImageViews in it and some standard and customized/subclassed TableViews and TableViewCells. Some elements are located in xib files, others are code only.
Navigation and table contents itself work fine. However, I suffer some weird "animation" effects... I'm trying my best to describe them as good as possible.
1)
When navigating back and forth on the navigation stack, each time a view appears, it looks like the items of that view are re-layouted. When navigating from a subview back to the root view, it's ImageViews start off at some location where they shouldn't be and slide to the right location.
2)
TableViewCells "unfold/reveal" their content from top to bottom when appearing in the visible area, even when reloading without animation:
TableView.ReloadSections(new NSIndexSet(1), UITableViewRowAnimation.None);
Scrolling down the table, each cell seems to trigger it's own "unfolding" animation separately as soon as it becomes visible.
3)
Scroll bars of TableViews slide from view to view.
For example, when tapping a cell that pushes another TableView on the stack:
- Parent table slides out to the left / sub-table slides in from the right (as it should)
- When sub-table has fully appeared, it's visible cells "unfold" from top (of the table) to bottom
- Finally, when this weird cell unfolding has finished, the scroll bar slides in from the left (where the parent table "is") to it's correct location on the right side. So it looks like it is reusing the scroll bar of the parent table.
4)
When displaying the network activity indicator...
UIApplication.SharedApplication.NetworkActivityIndicatorVisible = true;
... it appears where the network carrier name is (left-most on the status bar) and slides to it's intended location (next to signal strength indicator). The same happens to the "You are being located" arrow. When starting a LocationManager, the arrow appears on the carrier name and slides to the right.
All this animation and slide action is really irritating and distracting.
I checked on some other MonoTouch apps on the AppStore, none are suffering from this.
What have I done wrong with my application?
I'm really grateful for hints on what might cause this weird behavior and how to disable it.
I had this just today - I'd performed some animations in my app using
UIView.BeginAnimations("AnimationName");
UIView.SetAnimationDuration(0.5f);
// and so on...
and it turns out I hadn't actually committed my animations (using:
UIView.CommitAnimations();
ensuring I had called CommitAnimations() got rid of this behaviour!