1
votes

I am developing an iOS app and ran into a weird problem. I am doing a log of resizing of views and so on view did load, I have an ivar that holds the initial size of the view that I sized in the Interface Builder. The Initial CGFrame rect is: (x = 0, y = 63, width = 284, height = 705). The code I use to hold the initial value is:

filesFrame = self.fileView.frame;

and the only places i touch self.fileView.frame is:

 self.fileView.frame = filesFrame;
 self.fileView.frame = fullFilesFrame;    

These are in two separate spots not right after each other fullFilesFrame is defined as:

fullFilesFrame = CGRectMake(self.view.frame.origin.x,self.view.frame.origin.y+63,
    self.view.frame.size.height,self.view.frame.size.width+63);

When I check my values after I resize back to the initial frame, The frame rect is now origin CGPoint (x=0, y=63) CGSize (width=28, height=961)

how can this be? This is the first time I'm dealing with resizing of views, and Im fairly new to iOS as well.

1
probably it's because of autoresizing masks being set up incorrectly. And are you using autolayout?kambala

1 Answers

1
votes

I was going to put this in a comment, but it's too long, so:

One trick I like in these situations is to override setFrame: in the class of the view I'm having trouble with, and set a break point in that overridden method. If you do that then you can see when the frame changes and take a look at the call stack.

It's not always totally straight forward, overriding setFrame:. The frame property can be set directly but it can also be derived from the view's bounds and center, so you might need to look for things setting the view's bounds or the view's center instead of the frame.

Also if the view has a non-identity transform, that will make the frame property behave very strangely. If you are setting non-identity transforms on your view you should just avoid the frame property altogether.