🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.next.programmer
Article #1297

Re: NXBrowser problem...<long>

#1297
From: Tim McClarren
Date: Wed, 07 Oct 1992 16:55
97 lines
5108 bytes
szakhour@next.com (Sharon Zakhour) writes:


<let's see, what do I rip out and what do I leave in>

>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.

Okay...I can't beleive this is going around yet again.  Anyways, I got
mail after posting the original problem from Rick Maurer and Scott Hess,
both of which identified the problem I was experiencing properly and
offered me a solution which did work, albeit cumbersome.  It involved 
using "loadColumnZero" and having either your outlet-setting routine do it
or doing it in appDidInit, although the latter involves also adding a kludge
Boolean so that you don't actually load any cells in the "load" routine
the first time through.  According to Rick the Boolean wasn't necessary
under 2.1 because "loadColumnZero" wasn't called until he had already
set the cell prototype.

The Control's +setCellClass method wasn't part of the problem and I was in fact
calling the right routine.

>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;
>}

These are in fact the two "fixes" that Rick and Scott suggested, except
Scott's code snippet did in fact have a "loadColumnZero" call in it
and he was using the outlet init as his place to set the browser.
He didn't say whether it was 2.1 or 3.0 though.

But guess what?  I'm instantiating a subclass of NXBrowser from a .nib
file and have initFrame overriden and that works fine!  I was not
successful in doing it inside -init or inside +initialize, and it's now
pretty obvious that +initialize was bad place to try anyways.

I suspect that the only reason I'm getting "initFrame" is because I'm
a Custom View object, but it seems to work fine and doesn't involve
an additional call to "loadColumnZero" which seemed a major kludge to
me, so I'm going to stick with it for now...here's a stack crawl:

#0  -[HDFObjectBrowser initFrame:] (self=0x1db6e8, _cmd=0x618694b,
		frameRect=0x1da418) at HDFObjectBrowser.m:11
#1  0x6049af0 in -[CustomView nibInstantiate] ()
#2  0x6029c3a in -[IBObjectData nibInstantiateIn:owner:] ()
#3  0x6026bf2 in loadObjectData ()
#4  0x602643a in -[Application loadNibFile:owner:withNames:fromZone:] ()
#5  0x6040092 in -[Application _loadNibSegment:section:owner:withNames:
		fromShlib:fromHeader:fromZone:] ()
#6  0x605d8ac in -[Application loadNibSection:owner:withNames:fromZone:] ()
#7  0x473e in -[HDFDoc initFromFile:] (self=0x17b194, _cmd=0x6187a03,
		file=0x3ffed76 "/LocalLibrary/hdf/coil.hdf") at HDFDoc.m:46

Any comments?

-- 
Tim McClarren     | "...a bajillion brilliant Jobsian lithium licks."
timm@ncsa.uiuc.edu|
(217)244-0015     |
Technical Details
Message-ID: <timm.718476933@xongmao>
Path: arc1-ca.pugleaf.net!sparky!uunet!think.com!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!xongmao!timm
References: <timm.717823827@xongmao> <5332@rosie.NeXT.COM>

Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.next.programmer
Path: arc1-ca.pugleaf.net!sparky!uunet!think.com!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!xongmao!timm
From: timm@xongmao.ncsa.uiuc.edu (Tim McClarren)
Subject: Re: NXBrowser problem...<long>
References: <timm.717823827@xongmao> <5332@rosie.NeXT.COM>
Message-ID: <timm.718476933@xongmao>
Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
Organization: University of Illinois at Urbana
Date: Wed, 7 Oct 1992 16:55:33 GMT
Lines: 97