Re: Phantom views? was RE: [Newbie] Uninitialized outlets?
Re: Phantom views? was RE: [Newbie] Uninitialized outlets?
- Subject: Re: Phantom views? was RE: [Newbie] Uninitialized outlets?
- From: Brent Gulanowski <email@hidden>
- Date: Thu, 06 Sep 2001 22:09:10 -0400
>
From: Henri Lamiraux <email@hidden>
>
Date: Thu, 6 Sep 2001 11:17:39 -0700
>
To: "Erik M. Buck" <email@hidden>
>
Cc: Brian Hook <email@hidden>, email@hidden
>
Subject: Re: Phantom views? was RE: [Newbie] Uninitialized outlets?
>
>
Saying that "views are special" is a bit misleading. You can have a
>
regular object on a palette (not a subclass of NSView) and still
>
instantiate this object when dragging it off the palette. Look at the
>
two formatters. There are not views but still when you drag them off the
>
palette and drop them on top of a text field you are creating an
>
instance of the formatter. It seems that views are special because we
>
usually have visual object in palettes but any type of objects can be in
>
there.
>
>
Everything dragged off a palette are instantiated (you basically make a
>
copy of the object that is in the palette). If an object (/class) is not
>
in a palette (like one of your controller object, subclass of NSObject
>
or NSWindowController) you then need to use the Instantiate menu item.
>
In this case a "instance" of the object will show up as an icon in the
>
IB document window.
>
Another way to think about it is that things dragged into windows are
"has-a" instances: The Window appears in the Icon View of the .nib window,
but the member instances it "has" are not visible there, only in the list
view (hit the disclosure triangle and you'll see all of your "ghost"
instances in a subservient role to the window). I'm being loose with the
terminology, but I hope the point is clear: use the list view to see
everything, and the icon view to see all of the instance variables which are
owned by... NSApplication. A check into the NSApplication.h shows
@interface NSApplication : NSResponder
{
/*All instance variables are private*/
NSEvent *_currentEvent;
void *_windowList;
id _keyWindow;
id _mainWindow;
[...]
so I figure that _windowList points to an array (NSArray or something more
primitive) of all of the other icons you see, which in turn point to their
subservient instance objects etc. It's a bit odd that the File Owner appears
to be at the same level as the windows, but I suppose it's more convenient
that way.
Another plus for the list view is that you can get nice outlet/action
diagrams.
BG
>
>
On Thursday, September 6, 2001, at 10:59 AM, Erik M. Buck wrote:
>
>
> In retrospect, I can see how easy it might be to think you have to
>
> instantiate your View subclass explicitly, but if you think about it,
>
> Views
>
> are special. The act of dragging the view from the palette
>
> instantiates it.
>
> When you drag a button (a subclass of view) from the palette you do not
>
> also
>
> instantiate the button with the menu. When you drag the Custom View
>
> from
>
> the palette, you are effectively instantiating it and telling it to
>
> replace
>
> itself with a custom subclass of view when the nib is loaded.
>
>
>
Henri Lamiraux
>
Engineering Manager
>
User Interface Tools Group
>
Apple
>
_______________________________________________
>
cocoa-dev mailing list
>
email@hidden
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev