Same question as https://stackoverflow.com/questions/3100878/ipad-frame-programmatically-doesnt-match-with-ib but no-one answered!
I created a UITableCell layout in IB, copied done the measurements of the UILabel frame and used them to programmatically resize the frame.
But the Y coordinate is out by about 13 pixels - WHY?
Frame in IB x:176 y:16
Frame in code to match X:176.0f, y:3.0f
Check your autoresizing masks and Origin positions.
Related
I'm running into a weird issue with my code and I hope someone else has better ideas on how to handle this.
**Summary of what I want to achieve: **
I have an editor that looks like this:
On the right side I have an inspector panel where I can manually change the frame of the currently selected view (which sits inside another NSView that's the document view of an NSScrollView).
**Summary of implementation: **
The main view inside the NSScrollView doesn't directly use autolayout, because I need to be able to set the frame manually, I leave the translatesAutoresizingMaskIntoConstraints property to true (default value) for all the subviews inside the NSScrollView. So I end up with constraints automatically created when I set the frame.
The problem:
When I set the frame, to let's say (1, 0, 100, 100) for some reason the autolayout engine will take in account the magnification value of the NSScrollView and will readjust the frame, so the final frame might end up looking like (1.74, 0, 100, 100). While I do understand this, the question is, can I disable this behavior? Is it possible to have frame value increments of 1.0 while making sure Autolayout doesn't screw the final frame regardless of the NSScrollView magnification value?
Thank you!
Autolayout views inside a magnified NSScrollView can give very strange values at times, and I haven't really figured out when and why.
I have approached a similar problem by adjusting the views' position manually according to magnification of superview, or by subclassing them and writing a method for them to take the magnification into account.
So, for example:
CGFloat factor = 1 / magnification;
element.frame = NSRectMake(x * factor, y * factor, ...);
Hope this helps.
I have a view 'a' which I am putting on scrollView.
The 'y' coordinate of 'a' is set to zero. And the scrollView dimensions are set accordingly, contentSize of scrollView is set to fit the view 'a'.
But still scrollview is shifting the view 'a' upwards.
What could be the reason?
Thank you,
To start with, here are a few things to check:
What is the frame of the view a? Verify that a.frame.origin.y is 0.
What are the bounds of the scrollView? Verify that scrollView.bounds.origin.y is 0.
What is the size of the scrollView (scrollView.bounds.size)? This different is from its contentSize. Is it large enough to fit a inside of it?
I have an UIView that can grow dynamically in width. The view also have subviews located inside it's bounds.
Default behavior seems to be that when the view's frame grows along the x axis, increasing frame.size.width, it always grows at the right edge, keeping the subviews fixed as if there were a fix left margin. However, when I want to expand the view on the left edge this doesn't work because of this behavior. In this case I want it to behave in a mirrored way, as if there were a fix right margin. I could of course "manually" move all subviews so it looks like that is the case, but that seems really awkward since there could be plenty of them.
So I guess the question really is if there is a way to shift a views bounds relative to it's subviews? Is maybe autoresizingMask the way to do this?
Thanks.
Maybe you should take a look at the AutoresizingMask property of a UIView subclass :-)
For example, if you have a UILabel called labelVideoTitle, you could set a mask like this :
[ labelVideoTitle setAutoresizingMask:UIViewAutoresizingFlexibleWidth ];
You can by the way add 2 mask at once like :
[ labelVideoTitle setAutoresizingMask:UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight ];
Good Luck !
Edit : To increase the parent view frame size at the left edge, you could change too its X position to the left to give the impression wanted ^^ For example if you add 10 pt to the width, try modifying the X origin -10 pt :-)
In interface builder, you can graphically indicate in the CMD-3 (little ruler icon) Size Inspector what each element in your view should do when the parent view is resized: you can indicate which borders (top, left, right, bottom), the given element should "stick to" when the parent view is resized. You can also indicate whether the given element should itself resize (in either width or height) or stay the same size. Underneath the hood, this sets the autoresize mask for the UIView element you're editing, but especially for making an element stick to a particular border, Interface Builder is the way to go.
IB Size Inspector also has a neat little animation that shows you the effect on a hypothetical element (little red square) during a resize, given your settings to the left.
I have to do this:
1:CGRect originalSubviewFrame = subview.frame;
2:view.frame = (CGRect)newFrame;
3:subview.frame = originalSubviewFrame;
I think instructions 1 and 3 shouldn't be there but if I don't restore the subview shape, it change for some reason!?!?
I read the documentation but it's unclear.
If subview is a subview of view then whether it's frame changes when view's frame changed depends on whether view.autoresizesSubviews is YES and if so, how that manifests is determined by subview.autoresizingMask.
I encourage you to read the UIView documentation regarding those two properties.
I have a custom table cell which contains a number of UILabels. At runtime, I am adjusting the height of the labels to fit their contents using sizeWithFont:constrainedToSize:lineBreakMode: and repositioning them accordingly. The last label in the cell contains a large amount of text, causing it to wrap, and I'm having a very odd problem. Although the sizeWithFont call returns the correct size, and I'm setting the UILabel's frame to that height, it draws a couple of lines short. This screenshot illustrates what I'm talking about:
In this example, the height of the full block of text should be 90 (as checked in Interface Builder), and that's what returns from sizeWithFont. It's also the height that the UILabel's frame is set to, which I have verified by logging and also by stopping execution and inspecting the value. However, as you can see, it's clearly not drawing the full 90 pixels high, although it's correctly allocating the space for it (the thin black line above 'Edited' is the table cell border). I'm completely perplexed. If anyone can offer some insight as to why it's behaving this way, I would be very grateful.
At last, a solution!
Turns out that the cell does layout twice -- once during heightForRowAtIndexPath, which is where I tweak all the heights of the subviews and the cell, and later during some untraceable transaction originating in __CFRunLoopDoObservers. How did I trace this? I added a layoutSubviews override to my custom table view cell class so I could breakpoint it.
During the second pass, the last UILabel subview was getting set to a shorter height than I set it to, probably in accordance with some arcane autoresizing rules. (Yes, I tried tweaking all of those settings first, with no success.) As it turns out, merely doing nothing in layoutSubviews disabled this framework behavior, allowing me to completely control how my views draw.
With iOS 8 it doesn't work anymore like this. Implementing layoutSubviews alone doesn't do the trick, because the layout of subviews have already changed when the method is called.
I have found 2 solutions:
adding NSLayoutConstraint to layout the subviews programmatically
implementing subview's layoutSubviews and change the frame
An example für solution 2:
- (void)layoutSubviews
{
[super layoutSubviews];
CGRect frame = self.frame;
frame.size.height = 39.f;
self.frame = frame;
}
I've fought with similar problems. It was to do with other properties being set in previous incarnations of the cell. To find it / prove it I changed the reuseidentifer for the offending cell to make sure it was a unique cell.