I have a TableView in my application and I've created a centered label inside TableViewCell that I'm placing in the view. When TableView is in standard mode everything is ok and the label is really centered. However when I change the mode to grouped then the label is displayed slightly to the right. I suspect this is because in grouped mode the table is a bit shorter then in standard mode and since I've centered it for standard view in Interface Builder it's just being moved to the right.
I'd like to know if there's a way to automatically have centered TableViewCell label adjust it's parameters so it appears centered in grouped TableView or do I need to make it a bit shorter and move it a bit to the left manually to get what I want?
Assuming that the table will be initialized with a centered label, it should respond properly to future changes in width when you set its autoresizingMask to UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleRightMargin. But as far as I know you can't change a table's style after creation, so I'm not sure if this approach will fix your problem.
I've found a solution. I'm not very happy with it but it works. I just resized TableViewCell and it's contents to 300px width instead of default 320 and it fits ok.
Related
I'm running into something weird when using UIDatePicker elements with Storyboards in iOS 7. In the Storyboard, the date picker has a fixed height of 162. In reality, however, the element takes up more space than that. So this
turns into this:
so I have to move everything below it down, guessing and eyeballing how much space the date picker will actually use. Is this a bug? Am I doing something wrong? To be clear, the date picker is totally transparent - can't figure out a way around that. The white background at the top is the main UIView, and the gray background is the background of the UITableView embedded inside the container view.
I can confirm that using UI(Date)Picker in storyboards has a different height (162.0) than in "reality" (216.0). Therefore you have to adjust the space to container view to fit that "real" date picker height or try to solve it using auto-layout.
Here is a funny trick I just found: put the UIDatePicker inside a dedicated view with a constraint of 162 points in height (add 0 point vertical constraints from top and bottom of the picker to this new superview). This seems to have the effect of forcing the picker to keep the size of 162 points.
You can add the option of clipping the subviews to be sure that the UIDatePicker will not escape from its new prison.
EDIT: after some more tests, it seems that by just adding a height constraint of 162 points to the UIDatePicker, it will keep its "IB size". And, to answer #Andrew's comment, here is what it will look like:
You can change the width and height by simply giving it width and height constraints. Without doing that, the UIDatePicker just acts weird, I've found.
Setting clipsToBounds property to YES on my UIDatePicker object helped me.
datePicker.clipsToBounds = YES;
For XIB's you can directly tick the checkbox for Clip Subviews :
I am creating an iPad view which has a tableview as a subview. The tableview only takes a small portion of the screen and is somewhere near the middle of the screen and it contains some menu items. I want people to be about to scroll this tableview up and down however I do not like how the cells disappear against a hard edge. When I set clipsToBounds to false, I get what I want in that the hard edge is not there anymore but the top/bottom cell disappears when the tableview needs that cell for recycling. Is there a common technique to avoid this hard-edge of when the cells scroll up against the tableview's bounds? I was thinking of adding gradient alpha masks on a parent container view but it seems a bit over the top.
There are no hard and fast rule about this, but you certainly can do whatever you feel best. What I would do in a case of floating tableView is giving it a nice border using layer. It is easy to code (2~3 lines). Round the edge to make it pretty.
If you want to drop shadow, it gets a little more complicated but possible. Just draw a bezier curve path of a rectangle (where you want your shadow to appear). Assign that CALayer shadowPath. Then add it to the table.
You can also gradient an alpha to make it appear shadow like.
But I would suggest, you set clipsToBounds to YES since it looks horrible otherwise, given the fact that the table 'floats' somewhere in your view.
For example, on a UIView, from left to right there are three buttons:,button1,button2,button3.
When button 1 become wider, such as its width become twice as its original width, is there any interface builder way that can make button2&3 move right automatically?
sorry for I didn't make my question clear.
I mean such kind of size change: I push button1, then I change it's frame in my code, not caused by the change of text in butotn1. I want button2&3 to move right automatically, keeping the width of the gap between button 1 and 2 unchanged.
Thanks everyone.
IB can be used only for initional positioning of views.
True, you can also define autoresizing masks of the views but that's about it.
Any additional laying out should be done in code.
I could be wrong, but I don't know of any way you can do this in IB. It's pretty straight forward in code though, just link the buttons to some IBOutlets and check the sizes of the images of the buttons (myUIImage.size), then adjust the frames of the buttons (do it in viewWillAppear).
Seen your edit - if you're adjusting its size using code, adjust its position too.
If your buttons are in a row at the bottom of the screen, consider using a UIToolBar. Its UIBarButtonItem objects automatically adjust to fit each other's width changes. For more generic cases, you'll need to recalculate positions and sizes as in Franklyn Weber's answer.
Yes - by using autoresizing masks. If you allow the margins to be flexible (no red lines connecting the frame to the superview's frame) and allow flexible width and height, the buttons will size and move proportionally.
OK, so I am learning to use UIScrollView in interface builder. since the scrollView itself does not have any content, I created another view, the contentView, to hold my controls and scrollable content. into this view I place controls, labels, etc and then in my code i set the contentSize of the scrollView to the size of this contentView.
My question seems stunningly simple and so obvious that I must have missed something somewhere. when I created this XIB in IB I got your standard empty iPhone interface window. I dropped a scrollView on top of it, it took up the whole window. I dropped a view on top of that, it took up the whole scrollview. I added some controls, which so far I can still see inside the contentView rectangle in IB.
My question is how do I work on/add controls which lie outside of the visible part of the contentView in IB? LOL. it seems so simple, but i just don't get it. I can set the height of the content view or drag the rectangle to whatever I like (and indeed this is the whole point of having a scrollview) but the fixed UI window from IB won't expand so i can see the "offscreen" part of the contentView to add more controls. It's like it's just fixed at that size because that's the size of one iPhone screen and it won't let me make it any bigger/taller.
what did I do wrong?
-a
You need to turn off all simulated user interface elements (like the status bar) to be "undefined" except for size, which you select to be "Freeform" from the drop-down, and then you can set the view height using the Ruler tab to be whatever you like.
For example, here I've selected a photo view controller, and set the size in the right side bar to be "iPad Full Screen" - but I could also change that to "freeform" to set any height I wished.
First add a ViewController by any which way you prefer. Then in interface builder, click on the view controller Icon (on left). In the connections inspector click on the ruler icon "Show the size inspector". There will be option list for simulated size, change to "Freeform" and increase the height to any size you want. Hope this helps.
neeever mind. you drag the content view up so that some controls are offscreen and then add more controls/expand to the part you just made visible by moving the top stuff off the top. in effect, you physically scroll the contentView in IB by dragging it with the mouse. seems a smidge counterintuitive, but whatever.
Set simulated size to freeform for the the view controller to a large enough size that you can add in your controls
You don't have to create a view to place inside the scrollview if you don't want. In your case, it sounds like it doesn't make much sense.
As for the second part of your question, you can place items directly on the scrollview (it is a view afterall), as subviews. If you want them to be off screen, then just set their frame up to be at those particular x, y coordinates you want it to be at. You will have to ensure your scrollview's contentSize property is large enough though to house your entire content, this is what allows scrolling horizontally/vertically.
You probably want to do the offscreen elements programmaticly instead of using xibs.
This seems like it should be simple but I can't work out how to do it.
I've created a UITextView in interface builder. It doesn't sit in a table cell or anything fancy like that.
What I'd like to do is have the UITextView scroll itself to the left when the user has typed their way all the way to the right margin.
At the moment it just does a word wrap, I understand the word wrap makes sense in most situations but I need it to scroll instead. What I'm after is the same behavior it exhibits vertically.
I've tried adjusting the content size of the UITextView in viewDidLoad and also in viewDidAppear and that doesn't make a difference.
I've also played with the inset settings in IB but that doesn't affect the scrollable size, just WHERE it's displayed.
Does anyone have any ideas?
If you only need a single line of text that scrolls, you would probably be better served by a UITextField. UITextViews are meant for multi-line text input, which is why word wrap is the default. You can't, as far as I know, override that behavior.
Ok, it doesn't look like it can be done exactly how I wanted but I've come up with a hack to get me there.
Let's say I want a scrollable width of 600 and a visible width of 250.
The first step is to make the UITextView a wide as the area you want to be scrollable. So what you would have put into contentSize, in this case 600.
Then the right inset is set to the difference between the actual width and the width you wanted. In this case 350.
This way cursor is restrained to the width you need BUT there is text visible to the right of your desired width, after all, the UITextView IS 600 pixels wide.
Now here's where the really hackish bit comes in, don't read on if you're sensitive or have a weak stomach.
Get an image of the user interface to the right where UITextView should end. Insert it into the NIB as an UIImage view and put it back in it's place, making sure that it's on top of the UITextView.
When the view is displayed, the cutout sits on top of the UITextView and hides the text overrun.
I'm not proud, but it works.