iOS 7 UIDatePicker height inconsistency?

Question

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.

Solution 1

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.

Solution 2

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:

Solution 3

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.

Solution 4

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 :

View more solutions

Comments

[Andrew]

Do you think this is just a bug?

[dwery]

Have you tried setting edgesForExtendedLayout = UIRectEdgeNone on the controller?

[Andrew]

No, I haven't. I've long since moved on from that part of the app and since the problem doesn't actually break anything (after moving the rest of the content down), I'm happy leaving it as it is for now.

[2mia]

ha, could it be a typo, 162 vs 216 ? :)

[serget]

What is interesting, XCode 5.0.2 crashes the moment you try to change UIDatePicker's intrinsic size in IBuilder from Default to Height=216

[Andrew]

Doesn't that cut off the bottom of the wheels? It looks like it's designed to be 216px.

[MonsieurDart]

Nope, it seems to be redrawn specially for this height. See my edit.

[Andrew]

Wow, and the plot thickens! Thanks for the edit; this is helpful information.

[pronebird]

It's 162 in reality, not 216

[Majster]

@Andy Logging the size using NSStringFromCGRect(datepicker.bounds) gives {{0, 0}, {320, 216}}.

[pronebird]

@Majster I was resizing it in code for my cell so it seems 216 is a natural size yes.

[Mike Abdullah]

That happens to be the height that the Calendar app uses when in landscape. Seems Apple have a special case of some kind to handle the cramped space available at that point.

[pnizzle]

@MonsieurDart I know this is a stupid question, but I am lost on what you mean by "height constraint"?

[MonsieurDart]

@pnizzle I mean adding a auto-layout constraint to force the height of the picker. Hope this is clearer. :-)

[pnizzle]

@MonsieurDart oh, right. I have been avoiding auto layout, shamefully using the old-school autoResizingMasks, thats why I was confused.