Re: Interface Builder Questions...
Re: Interface Builder Questions...
- Subject: Re: Interface Builder Questions...
- From: Jonathan Hess <email@hidden>
- Date: Mon, 6 Jul 2009 16:22:40 -0700
On Jun 28, 2009, at 12:59 PM, Phil Hystad wrote:
I am new to Interface Builder and I am still trying to figure out
some subtle details of how things work. And, my frustration level
is growing because although I have access to a very rich set of
documentation, a number of questions I have pondered are not
answered. Some of these may be rather silly but remember I am very
new to Cocoa and Interface Builder.
(1) The default Cocoa Application created by Xcode creates a simple
application with a single window and a default menu (among other
things I presume). This window has a content view which I am
assuming is an instance of NSView but I actually can't find out if
that is true. Therefore, are there any inspectors that tell me the
actual class used for a particular view. The class identity part of
the Inspector for the content view suggests has a drop down that
allows me to choose various classes but there must be a specific
class that is used already. How do I find this?
If you read the text content of that combo box before editing it, it
will tell you the type of the control. For this case, it should show
"NSView" in light grey text. Light grey text means you haven't set the
value, and by default it is NSView. Now, there's a bit of a subtlety
here. The combo box tells you what that object's type will be at
runtime, not the type of the object at design time. If you change the
value from NSView to NSButton, the content view won't morph into an
NSButton until you run your application. The list of options in the
combo box's drop down is all legal classes for that object, which will
be all subclasses of NSView.
(2) I am trying to understand how the window sizing features of the
view inspector relate to the window itself. As best as I can tell,
none of the actual window sizing features for the content view are
usable as they do not really seem to do anything. Is this true? Is
it possibly the case that the content view, being bound to the
window frame, is sized automatically based on the window size?
NSView's autoresizing features are used to indicate how a view resizes
in relation to its superview. The content view is conceptually at the
top of the view hierarchy and will always be sized to fill its window.
Normally you would set the auto resizing properties of the views that
are in the content view.
(3) Again, on the window sizing inspector, if I resize the window
using the resize thingy in the lower right hand corner, I can see
the updated pixel size in the inspector, but only after I stop
resizing. If I want to resize to a particular dimension, say 300 x
225 (or, whatever), it is a try this, check, try that check, and so
on. Is there a way to enable the size values of height and width to
resize dynamically as I change the window size? I have looked all
over the documentation and tried a lot of things but nothing seems
to make the behavior different.
Try selecting the window directly, and resize that with the inspector.
Interface Builder is disabling those size properties because the
window's content view's size is managed by the window.
(4) And, finally, on the window sizing inspector, in the part
called "autosizing" when I click on the content view (remember, it
is empty, just as created by Xcode), there is an animated image that
expands and contracts in size and I have absolutely no idea why it
is animated or what it means. Any help?
This animation will make more sense with a sub view that's in the
content view. Try adding a table view to the center of your window,
and then play with those values.
After you figure everything out, I'd really encourage you to file some
specific bug reports (http://bugreport.apple.com) about things you
felt were difficult to figure out.
Good luck -
Jon Hess
Thanks,
InterfaceBuilder newbie phil
_______________________________________________
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
_______________________________________________
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