A bit confused about NSView instances in Interface Builder

  • Hello all.

    I was studying an application's source code when I saw in the Instance
    pane of Interface Builder an icon identified by "View".

    I discovered that it is possible to instantiate NSView (sub)classes and
    when you do so a "View" icon appears in the IB's instances pane.

    Anyway I am a bit confused about the usage of those instances.
    I'll try to explain.

    When I double click a "View" instance a new window opens and I can add
    to it all the controls I want as I do, for example, with the main window.

    I thought that it was a way to "factorize" part of the interface by
    creating "view components" that could be reused. But I confused because
    things don't work as I expect and I cannot see what is the logic behind.

    For example: I create a subclass of NSView, let's say A. Then I
    instantiate A and a "View" icon appears in the IB's instances pane.
    Double clicking A opens up a window where I add a bunch of control.
    Then I go to the main window, I drop a custom view control and I set its
    custom class to A. I expected that the controls that I put in the A
    design window would appear but nothing happens.

    Moreover if I generate the files for A in the XCode none of the controls
      I have added is present in the structure of the class.

    So the question is: what are view instances useful for and how are they
    used?

    I am sorry if the answer to this question is trivial but I cannot see
    what it is.

    Thank you.
  • On 1 okt 2006, at 19.41, Fabio Mancinelli wrote:

    > I thought that it was a way to "factorize" part of the interface by
    > creating "view components" that could be reused. But I confused
    > because things don't work as I expect and I cannot see what is the
    > logic behind.

    Your general line of thinking is correct.

    > Then I go to the main window, I drop a custom view control and I
    > set its custom class to A. I expected that the controls that I put
    > in the A design window would appear but nothing happens.
    >
    > Moreover if I generate the files for A in the XCode none of the
    > controls  I have added is present in the structure of the class.

    What you've described sounds interesting, and perhaps you should
    submit it to Apple as an enhancement request. However, that's not how
    Interface Builder works.

    > So the question is: what are view instances useful for and how are
    > they used?

    Nib files are used to hold user interface items that you want to use
    in an application. Often, the root item [*] will be a window, but
    that need not be the case. I will try to explain how it's used by an
    example.

    Consider an inspector panel - like the inspector in Interface
    Builder. It has several different "sub-pages" for different things to
    inspect. If you have one window that is used as a host for a wide
    variety of sub-pages like this, it can make sense to break out each
    such sub-panel into it's own nib file. This might even be a
    requirement, for example if your application has a plugin
    architecture, it might be that the plugins will provide their own sub-
    panels for the inspector. In such cases, it doesn't make sense to use
    a window as the root item for the sub-page nib files. Instead, you
    would use a view as the root item - much like you've discovered that
    you can do.

    So, what you would end up with is one nib file for the inspector
    window, and a lot of individual nib files for each sub-page in the
    inspector. The inspector class would then, at runtime, have to load
    (using the NSBundle nib loading API) each sub-page nib file as
    needed, and "manually" insert their views as appropriate.

    j o a r

    [*] There is really no such thing as a "root item", you can have any
    number of items at the root of the nib file, but that's how it's most
    often laid out.
  • When you instantiate the view, that means that when the nib file is loaded
    an instance of that class will be created. When you drag a control into the
    window and set its class to A, that means that when the nib file is loaded
    an instance of A will be created and placed in the window. Notice what's
    missing? No connection whatsoever between the two--that's what you're
    missing.

    Instantiating like what you tried for A is useful for controller and
    data-source kinds of classes, which typically other classes reference via
    outlets which you hook up in IB. Suppose you have several complex panes or
    groups in one window. Rather than putting all the controller logic in a
    single subclass of NSWindowController, you could make several
    sub-controllers for each pane, and your main controller would have IBOutlet
    MySubControllerClass1 * subcontroller1 and so on, and you'd make file's
    owner the class of the main controller, instantiate each subcontroller, and
    control-drag from the file's owner to each subcontroller, hooking up the
    subcontrollerx outlets to the instantiations. You might also hook various
    user interface items up to the subcontrollers as targets or delegates,
    instead of the main controller. You might also have outlets in the
    subcontrollers which get hooked up to the main controller, so they can query
    it or notify it of updates in the panes.

    OK, summary:

    1) Instantiation works for any Obj-C class. It just creates an instance of
    the class when the nib is loaded.

    2) The instance is not worth anything unless you hook up a reference to it
    and use it somehow. (Well, perhaps +init or -init or -awakeFromNib could
    have some side effect, but that seems unlikely to be a good design.)

    --
    Scott Ribe
    <scott_ribe...>
    http://www.killerbytes.com/
    (303) 722-0567 voice
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today