I've tried to modify a few traits of an existing UIView such as its frame and its backgroundColor, and nothing happens any time I do it. I've looked at some of the answers on here, but none of them have worked for me. I've been able to modify a UIView and then place it as a subview before, but never one that was in the xib or storyboard from the start (xib because I've been working an old project at my work). To be clear the views I've been trying to modify are not self.view, always subviews that were created before hand.
example code:
#property (strong, nonatomic) IBOutlet UIView *toEdit;
[_toEdit setFrame:CGRectMake(self.view.frame.origin.x, self.view.frame.origin.y, 200, 200)];
As explained here, have you tried connecting the elements in the xib to the code throughout Outlets? Ctrl+click on the ui element in the Interface Builder element and release on the relative property of the relative header.
In case you use an Autolayout, the Frame system changes totally and you will not be able anymore (lets say) to edit position directly if not using Constraints.
Related
I'm having a bit of trouble with the right parts of the view hierarchy in my iPhone app getting the touch events they should be. The code is all Swift in iOS 11.
I have a UIControl subclass which overrides beginTracking() and endTracking(). Originally, I had programmatically created a UIView, and then added an instance of my UIControl subclass as a subview. The code basically boiled down to:
myView = UIView()
view.addSubview(myView)
// add autolayout constraints for the view
myControl = TheControl(frame: theFrame)
myView.addSubview(myControl)
// add autolayout constraints for the control
This worked fine, but I wanted to have myView in Interface Builder to make autolayout a bit easier. So I got rid of the 'myView=UIView()' and 'view.addSubview(myView)' lines, created the view in IB, and connected it to an outlet in the view controller. The rest of the code stayed the same. So I programmatically create myControl, and add it as a subview of myView. Now that I have done this, myControl no longer receives touch events.
I can't figure out what is happening differently by doing this in Interface Builder vs. in code. I have toggled on and off "User Interaction Enabled" on myView in IB, and as far as I can tell it doesn't make any difference.
What am I doing wrong here?
I have a nib that has the standard UIView and I've also included a UIScrollView as an IBOutlet (yes, it is hooked up), not as a subview of the main UIView, but just out on its own. Autolayout is turned off. The scroll view has several subviews and is larger than the main view. In viewWillAppear:, I set the content size of the UIScrollView to its current frame size, and then set its frame to the size of the main view, and add it as a subview of the main view.
Unfortunately, nothing is showing up. When I NSLog the frame of my UIScrollView, it is coming back as {0, 0, 0, 0} (CGRectZero). I thought this was odd, so I went back and tried logging the frame before I do any changes to it. Still zeroes. Logged it out in viewDidLoad before anything is done to any of my view elements. Still zeroes. (FWIW in my nib, the frame is {0, 0, 320, 896})
I've had this issue with several of my controllers, but it seems to be hit or miss. Sometimes it works, other times I get the empty frame. Typically, recreating everything from scratch seems to fix the issue, but I don't know why, as I'm setting everything up the same both times.
Running Xcode version 6.1 (6A1052d), iOS SDK 8.1 with a deployment target of 7.0
Let me know if there is any other relevant information I can give that might help.
EDIT 1: To address the questions about my UIScrollView being a "subview", here is what my view heirarchy looks like in the document outline:
As you can see, the UIScrollView is a "subview" of the view controller, but is not a subview of the "main" UIView which has the controller's view outlet.
EDIT 2: More images and some code. Here is a better look at how my nib is set up:
I add my scrollView to the main UIView as follows:
- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:animated];
scrollView.contentSize = scrollView.frame.size;
scrollView setFrame:CGRectMake(0, 100, self.view.frame.size.width, self.view.frame.size.height - 100); // I slightly modified this because there are other variables that determine its Y position and height
[self.view addSubview:scrollView]
}
But I still don't think any of that code matters- for whatever reason, my UIScrollView is coming back nil. If I have the view created in my nib, the outlet is connected properly, how would the view still be nil? I'm creating my controller via initWithNibName I've tried cleaning the project, and removing the app and reinstalling.
Best guess on an answer, and some comments:
Nibs are simply serialised object trees. You can have as many view as you want as root. The problem (big one!) is that if they are not "connected" to outlets that retain them, at some point you will loose those references.
Since your UIScrollView is not a subview of the main view controller view on the Nib, it's not retained by it (views retain their subviews). So, it's up to you to retain it on your view controller.
My guess is that at the point you are trying to set the frame in the View Controller, the scroll view is already gone. I'm not sure how sure when are you doing it, but it might be after some run loops, so the unretained scroll view is dealloced.
Workarounds:
Instead of a variable for the IBOutlet, use a strong property (#property (strong, nonatomic) IBOutlet UIScrollView *scrollView).
Add the __strong qualifier to the variable.
Add the UIScrollView as a subview within the nib, so when the object tree is deserialised it's already retained by its parent.
Given that you purposefully put the UIScrollView outside of the main view hierarchy, I'm assuming you don't want option 3, so I'll just go with 1.
First, you might want to consider using autolayout. It makes things a lot easier once you make the investment to understand how it works. Check out this Apple doc on using UIScrollview with autolayout.
If that's not an option, the problem is that you're setting up your scrollView at the wrong point in the cycle. The scrollView needs a chance to lay itself out. By the time you hit viewWillAppear, you've missed sub view layout.
So, you could try:
Configure your scrollView in willLayoutSubviews and set its setNeedsLayout property.
Explicitly call layoutIfNeeded on your scrollView in viewWillAppear. The idea is to force another subview layout cycle. But, I'm not 100% sure it would work -- it might be too late at that point.
Note that the size of the main view (self.view) isn't determined until viewDidAppear. It's not always correct in viewWillAppear. So, you have a problem in your setup: you can't really set up your scrollView until you know your view size, but you don't know that until it's too late! You might want to redesign to avoid that dependency.
Using Xcode5 and auto layout. Consider following scenario:
I have an outlet for "Dispatch" UITextField
#property (weak, nonatomic) IBOutlet UITextField *dispatchTextField;
If user clicks "Camera" button I want to hide dispatchTextField and move "Subject" and "Body"(below) up.
This is not a real scenario but I'm facing tasks where I will be using this kind of technique. I've seen code samples where container size can be modified and so on. In XAML - there is "StackPanel", in Android there is similar controls where I can just hide this TextField and views below automatically spring up.
So, what is the proper way to do this in XCode5 with auto-layout?
I tried (with no luck)
self.recipientTextField.hidden = YES;
I also tried
[self.recipientTextField setFrame:CGRectMake(0, 0, 0, 0)];
[self.view layoutIfNeeded];
Add a height constraint to the text field. After making sure there are no conflicting vertical constraints, add a reference to this constraint in your view controller.
Add an action to the Camera button and connect it to the view controller. Whenever the button is tapped, you would set the constant property of the height constraint to zero.
Make sure that other views are setup to have constant vertical spacing with the text field you wish to shrink.
Quick question. Using IB, I have a subview in a ViewController. In that subview I have a label, which I would like to wire to my custom subview class. However, IB will not let me. What am I missing?
I also tried to add the label programmatically; however, it appears that the frame was not ever set. I could hard code the size of the label, but I could not make it dependent on the frame size of my subview, because the frame and the bounds were always zero rects, even after the view showed up in my view controller at a non zero size. Any ideas here would also be much appreciated.
You are actually completely right. It wont let you connect from IB to the Header of a custom view in Xcode 4.6.2
Personally I would file a Radar but I would want to do a bit more research to prove it and as this is a pattern I wouldn't ever use then I won't.
Fortunately you can get around it
Make sure your custom view is configured correctly in IB
and assuming you are setup something like this
Then you can manually declare in your header
#interface MyCustomView : UIView
#property (weak) IBOutlet UILabel *label;
#end
And drag FROM the dot that appears beside the property TO the label.
Or drag FROM the right-click HUD of the custom view TO the label.
Neither case will work by dragging from the label to the view.
In your header file, you need to define the label as an IBOutlet, then you can drag from your file's owner to the label.
IBOutlet * lblSomeLabel;
Disable AutoLayOut and try again.
I wrote a little UIView subclass to show a progress HUD. That HUD view works perfect but I faced a little problem in the last days.
In my application I'm presenting a UIViewController in a custom way. When the user selects a row in a tableView I'm creating an instance of my second viewController, move it to the current VC, set it's view's height to zero, add it as subview of the curren VC's view (at the position of the selected cell) and animate the height back to original.
The behaviour looks pretty cool and works great.
But when the second view is added as subview, I'm adding a HUD to this view. When the second view is resizing to the original height, the HUD sticks to the top of the view and is just a few pixels high:
I played around a bit with NSLayoutConstraints... But I didn't get it working until now...
Has someone a good idea on that one? Or does anybody know good and well explained resources on these constraints?
The HUD is actually a background view with the little window as subview. All other elements (the progress view, labels and so on) are subviews of the little window.
In terms of good resources, I definitely recommend WWDC2012's 3 videos: Introduction to Auto Layouts for OSX/iOS, Auto Layout by Example, and Best Practises for Mastering Auto Layout. These have some tips for looking at ambiguity in the layout and dealing with conflicts
Another great reference is Erica Sadun's iOS6 recipe book.
Re your problem. I'm assuming that you're not seeing an error message and you're laying out the progress HUD entirely in the XIB. If so, it sounds like you have two constraints that aren't behaving as you'd like from the xib - the height from the top of the superView and the height of the HUD
Firstly, create an outlet for the constraints to the .h file
#property (strong) IBOutlet NSLayoutConstraint *HUDSuperViewToHUDConstraint;
#property (strong) IBOutlet NSLayoutConstraint *HUDHeight;
Next, in the method in which you open the new viewController with the HUD remove the constraints so that there is no conflict when you first show the new view
[HUDSuperView removeConstraint:self.HUDSuperViewToHUDViewConstraint];
[HUDSuperView removeConstraint:self.HUDHeight];
After you've called [HUDSuperView layoutIfNeeded] for the first time, in the animation or wherever, add the constraints and call layoutIfNeeded again
[HUDSuperView addConstraint:self.HUDSuperViewToHUDViewConstraint];
[HUDSuperView addConstraint:self.HUDHeight];
[HUDSuperView layoutIfNeeded];
If you call these within an animateWithDuration it may even animate the appearance...cheesey
Hope this helps - it's probably more of a step toward the solution rather than the solution itself. Recommend minutes 17 and 53 in the AutoLayout by Example video too.
Steve