Re: [iPhone] can't get views not to slide off by the height of the status bar
Re: [iPhone] can't get views not to slide off by the height of the status bar
- Subject: Re: [iPhone] can't get views not to slide off by the height of the status bar
- From: Matt Neuburg <email@hidden>
- Date: Tue, 25 Jan 2011 12:41:41 -0800
On Tue, 25 Jan 2011 14:05:05 -0200, WT <email@hidden> said:
>While writing this reply, it occurred to me to try something I thought I had tried before but which I had not, namely, to turn off "resize view from nib" for the window root view controller (tabBarVC, in MainWindow.xib) and then make its view (loaded from a separate nib file, containing the fake tab bar controller) 480 pixels tall by not selecting a status bar in the simulated UI elements panel and by setting its frame to (0, 0, 320, 480). Nothing else is changed.
>
>And guess what... it works, which goes to show that just because a design is non-standard, it doesn't mean it's illegal in the sense you were referring to.
That isn't what it goes to show. What it goes to show is that it's possible to work around anything. Your views were arriving with a frame.origin.y value of 20; you could have worked around the problem by setting that to 0 as you put the view into the interface. I knew about that, and I knew about the trick you are now using, but I purposely didn't tell you about them in my previous note (though I did fear that you might discover them anyway). You're just putting a band-aid on a self-inflicted wound. The engine warning light on your car has come on and you're responding by putting black tape over it. The correct procedure is to go back to the root cause, which is how you're obtaining those views in the first place.
You should not be using view controllers merely as dumpster divers to load nib files and extract their contents in a semi-automatic way. As I said in my previous note, if you want to store those views in nibs, fine, but then the way to extract those views is with a normal class whose job is to function as the File Owner for the nib and pick up the desired view through an outlet. Using a view controller is wrong because it does all kinds of other stuff not appropriate to this situation.
You asked for further support from the documentation for my statement that you're using view controllers for views that are going into the wrong sort of place in your view hierarchy. The devil can quote scripture for his own purposes, but since one of the view controllers you're misusing is a UINavigationController, I'll just paste in, directly from the docs, this convenient list of the places where such a controller is permitted:
• Install it directly in your application’s main window.
• Install it as the root view controller of a tab in a tab bar interface.
• Install it as one of the two root view controllers in a split view interface. (iPad only)
• Present it modally or otherwise use it as a standalone view controller that you can display and dismiss as needed.
• Display it from a popover. (iPad only)
The place you're putting it is none of those.
Recall that your original note said explicitly that you did *not* want a "just do this" answer; you wanted a more general explanation of what was causing this issue. I provided one, and you immediately rejected it, and abandoned your stated principles and contented yourself with your own "just do this" answer, ending up no wiser than before about how view controllers work and how they are intended to be used. m.
--
matt neuburg, phd = email@hidden, <http://www.apeth.net/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.apeth.net/matt/default.html#applescriptthings_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden