🚀 go-pugleaf

I wanted to also post some information which explains more fully some of the  
nuances of the factory +setCellClass: method...


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.

The disadvantage of setting the cell class using the factory method  
+setCellClass, is that it will change the cell for EVERY instance of that class  
-- including subclasses.  For example, if you subclass Button and add a  
+initialize method to look like:

+initialize
{
	[super initialize];
	[MyButton  setCellClass: [MyButtonCell class]];
	return self;
}
@end

Then not only will all instances of MyButton have MyButtonCell as a cell class,  
but so will all instances of Button!  This is probably non-desirable behavior  
for most applications, so for this case we recommend using this approach:

- initFrame:(const NXRect *)frameRect
{
    id newTextField;
   
    [[self class] setCellClass: [TurboTFCell class]];
    newTextField = [super initFrame:frameRect];
    [[self class] setCellClass: [TextFieldCell class]];
    return newTextField;
}

Note that this code is excerpted from the 2.0/3.0 MiniExample TextORama  
[TurboTextField.m] and the README explains why it is implemented this way [in  
change history -- 4/27/92].  Basically the cell prototype is created inside of  
the call to [super initFrame:frameRect] so we are still setting the class PRIOR  
to the creation of the cell.

See my other followup to this thread for more information in the instance  
method of setCellClass available only to NXBrowser and it's subclasses.

Sharon Zakhour
Developer Support