🚀 go-pugleaf

Tim McClarren writes
| I am experiencing a problem with the NXBrowser class under
| 3.0.  In effect, the manual page says to use the method "setCellClass:" to
| set the class of the cells that the Browser is to create inside the
| new columns it makes.  I then use the "addRow" method of class Matrix
| and it seems that the new cells are in fact NOT of the class I had
| specified.  I am subclassing NXBrowserCell, so that isn't the problem
| I don't think.  How do I get NXBrowser to behave properly without going
| around it's back and setting the cell prototype in the Matrix like the
| documentation specifically warns against doing?


First of all, it's important to note that there are two setCellClass mechanisms  
in the AppKit's control classes.  The Control class itself offers a  
+setCellClass: factory method.  This method must be called before any Cell  
instances are created -- typically in the +initialize method as described in  
NeXTanswer appkit.761.

However, NXBrowser is a special beast and offers an instance method of  
-setCellClass:.  The 3.0 documentation specifically states that you should use  
the instance -setCellClass: method for NXBrowser and NOT the factory method  
inherited from Control.  [See the -setCellClass: method description in the  
NXBrowser spec sheet.]  The obvious advantage to this implementation is that  
you can change the cell class for a specific instance of NXBrowser without  
changing it for ALL browsers.

You need to call -setCellClass: before loadColumnZero is called.  If you create  
an NXBrowser instance programmatically -initFrame: would be a good place.   
However, when you are trying to change the cell class for an NXBrowser that was  
instantiated in a nib file -initFrame: will not get called (and therefore the  
cell class will not get set).  In this case, you might want to do it in an  
outlet initialization.  If you wait to make the call until AFTER the  
loadNibSection, then you will need to reload column zero.  (Between the outlet  
initialization call and the completion of the loadNibSection, the first column  
has already been loaded with the default prototype Cell.)  So if you set the  
cell class in -appDidInit:, you would need to do this:

- appDidInit:sender
{
    [browser setCellClass:[myCustomCell class]];
    [browser loadColumnZero];
    return self;
}

Whereas you wouldn't need the loadColumnZero in the outlet initialization:

- setMyBrowser:anOutlet
{
    myBrowser = anOutlet;
    [myBrowser setCellClass: [myCustomCell class]];
    return self;
}

So, based on Tim's symptoms above, it looks like he might be trying to set the  
cell class either:

- inside of -initFrame: or
- after -loadNibSection: and is not re-loading the first column


Brian Willoughby writes:
| After MUCH experimentation under 2.1, I found that -appDidInit: and  
| -setBrowserOutlet: were not reliable places to make the -setCellClass:
| call.  I subclassed NXBrowser and included the following class method:

| #mount _soap_box
| This is a prime example of how NeXTanswers is nearly useless.  appkit.827  
| says to -setCellClass inside -initFrame:, appkit.816 says to -setCellClass  
| in -appDidInit:, appkit.761 says that you must -setCellClass in +initialize  
| because -init is too late, implying that -appDidInit would be far too late.   
| It took a great deal of experimentation and searching to figure out what 
| worked. Of course the simpler approaches didn't work and they were what I 
| tried first.
| #dismount _soap_box

I'm sorry to hear that you find NeXTanswers "nearly useless".  We write these  
in our spare time and it's disappointing to hear that they are not being well  
received.  We try to police them for accuracy and content but sometimes errors  
do creep in.  We are interested in keeping them as accurate and up to date as  
possible and we hope that when you find errors or inconsistencies that you will  
send them to nextanswers@next.com.  Help us to help the community.

The information I gave above for the 3.0 case is also true in the 2.x case  
although there were a couple of bugs that complicated matters.  For example,  
under 2.x no matter WHERE you called -setCellClass: for NXBrowser, you always  
needed to call loadColumnZero (unless you didn't care if the first column used  
the default cell).  Also, this approach didn't work at all if you set  
reuseColumns:YES on the browser -- this would crash the application.  These  
bugs have all been cleaned up for 3.0.


Sharon Zakhour
Developer Support 

P.S. I do plan to update appkit.761 to include more of this information.  It is  
accurate but could stand some fleshing out.