Changeset 8499


Ignore:
Timestamp:
Feb 16, 2008, 1:10:31 AM (12 years ago)
Author:
mikel
Message:

added sections on nib-loading function, and nib unloading

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/source/examples/cocoa/nib-loading/HOWTO.html

    r8480 r8499  
    287287      </div>
    288288     
     289      <p>Cocoa provides no general nibfile-unloading API. Instead, if
     290      you want to unload a nib, the accepted approach is to close all
     291      the windows associated with a nibfile and release all the
     292      toplevel objects. This is one reason that you might want to use
     293      the <code>"NSNibTopLevelObjects"</code> key with the dictionary
     294      object that you pass
     295      to <code>loadNibFile:externalNameTable:withZone:</code>7mdash;to
     296      obtain a collection of toplevel objects that you release when
     297      the nibfile is no longer needed.</p>
     298
     299      <p>In document-based Cocoa applications, the main nibfile is
     300      usually owned by the application object, and is never unloaded
     301      while the appliation runs. Auxliliary nibfiles are normally
     302      owned by controller objects, usually instances of
     303      <code>NSWindowController</code> subclasses. When you
     304      use <code>NSWindowController</code> objects to load nibfiles,
     305      they take responsbility for loading and unloading nibfile
     306      objects.</p>
     307
     308      <p>When you're experimenting interactively with nibfile loading,
     309      you may not start out by
     310      creating <code>NSWindowController</code> objects to load
     311      nibfiles, and so you may need to do more of the object
     312      management yourself. On the one hand, loading nibfiles by hand
     313      is not likely to be the source of major application problems. On
     314      the other hand, if you experiement with nib-loading for a long
     315      time in an interactive session, it's possible that you'll end up
     316      with numerous discarded objects cluttering memory, along with
     317      various references to live and possibly released objects. Keep
     318      this in mind when using the Listener to explore Cocoa. You can
     319      always restore your Lisp system to a clean state by restarting
     320      it, but of course you then lose whatever state you have built up
     321      in your explorations. It's often a good idea to work from a text
     322      file rather than directly in the Listener, so that you have a
     323      record of the experimenting you've done. That way, if you need
     324      to start fresh (or if you accidentally cause the application to
     325      crash), you don't lose all the information you gained.</p>
     326
    289327    </div>
    290328
Note: See TracChangeset for help on using the changeset viewer.