Re: a bug in iphone SDK's creation of view based xib files.
Re: a bug in iphone SDK's creation of view based xib files.
- Subject: Re: a bug in iphone SDK's creation of view based xib files.
- From: Joey Hagedorn <email@hidden>
- Date: Thu, 3 Sep 2009 14:13:34 -0700
On Sep 3, 2009, at 5:21 AM, jon wrote:
Thanks for reporting a bug, this is the best way to get problems fixed.
the springs and struts are disabled on views with simulated user
interface attributes, so this is expected....... In this case,
it sounds like you expect the view provided in the UIViewController
Subclass with XIB file template to have the autosizing parameters
set differently.
if this were not a bug, then why is the First XIB created (which
is a UIView class also) set differently than the Second XIB which
is also the same Class?? ( I should have mentioned in the steps
that this is not a UIViewController subclass, that option should be
left off to create a regular "UIView" Class...) and should
provide exactly the same start point, since they after all should
be the same, yet they are not the same???
one has the struts/springs set differently than the other....
worse, disabled, so that no one can change them to be correct.
I am not disagreeing with you, I'm trying to clearly identify the
problem. The issue here is that the autoresizing options for the view
created with the UIViewController File Template does not match the
configuration of the XIB included in the UIViewController based
Application's view XIB file, that is it isn't set to autoresize height
and width.
Fortunately, if you turn off the simulated status bar on the view, you
can toggle the autoresizing freely from within Interface Builder.
(a second related thing is:) setting the Simulated Status Bar to
disabled, does not actually disable the status bar, (it does
inside of IB, but inside the iPhone simulator after it is compiled,
it does not) one has to also edit the XIB to actually turn off the
Status bar?? (maybe i am missing something there)
I cannot stress this enough; do not edit the XIB file by hand.
As Roland said, the Simulated Status Bar is just that, simulated, and
present to aid in designing your view. The XIB file contains objects
that are archived and at run time are recreated from the nib. The
status bar is not in a nib and is drawn as part of the system, so
controlling it is achieved by an API call or editing the Info.plist
file.
Perhaps you will find the Simulated Tab Bar more relevant. In each of
the view XIB files used in your app, it will make sense to turn on the
Simulated UITabBar at the bottom of the screen. In the root view
controller of the navigation controller, you'll also want to turn on a
simulated navigation bar. This way you can see how much space will be
taken up by a tab bar. In other contexts, it will give you a context
to edit a navigation item or tab bar item as well. Note that a tab bar
is not added to each of your view XIB files, but the layout metrics
are available for you to design your interface taking the height of
the tab bar into account.
which brings up another question? why does it matter that the
status bar be there or not? shouldn't you be able to adjust struts
and springs no matter if it is there or not? if one rotates the
view, the status bar rotates in the iphone simulator, shouldn't
the view also rotate and adjust it's view appropriately? right now
that is not happening.... shouldn't it for the second XIB view,
just like the first XIB view does correctly. (even if the status
bar is there, the first one is set correctly)
A view that has a Simulated Status Bar enabled is intended to be
controlled by a UIViewController. When you turn on the simulated
status bar, the view is sized to fit the screen and locked to that
size. Because the view is locked in its size, the controls for the
autoresizing behavior are disabled as well. I see the usability
concern here, but I hope the workaround of turning off the simulated
user interface elements will be sufficient for the time being.
Thanks,
Joey
_______________________________________________
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