Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!spool.mu.edu!agate!ziploc!eps
From: eps@toaster.SFSU.EDU (Eric P. Scott)
Newsgroups: comp.sys.next
Subject: Re: Programming Question
Message-ID: <1808@toaster.SFSU.EDU>
Date: 29 Jun 91 05:59:33 GMT
References: <1991Jun28.073504.16199@neon.Stanford.EDU>
Reply-To: eps@cs.SFSU.EDU (Eric P. Scott)
Organization: San Francisco State University
Lines: 77

In article <1991Jun28.073504.16199@neon.Stanford.EDU>
	zimmer@calvin.stanford.edu (Andrew Zimmerman) writes:
>In response to a question I had about the Button Class vs that ButtonCell
>Class, EPS explained that I should use a subclass of ButtonCell for
>my application. (I wanted to have multiple (more then 2) icons to represent
>the state of a Button.)

More specifically, override
 calcCellSize:inRect: (ButtonCell)
 doubleValue (ButtonCell)
 drawInside:inView: (ButtonCell)
 drawSelf:inView: (ButtonCell),
 floatValue (ButtonCell)
 getDrawRect: (ButtonCell)
 getIconRect: (ButtonCell)
 incrementState (Cell)
 intValue (ButtonCell)
 read: (ButtonCell)
 setDoubleValue: (ButtonCell)
 setFloatValue: (ButtonCell)
 setIntValue: (ButtonCell)
 setState: (Cell)
 state (Cell)
 write: (ButtonCell)
and possibly also
 calcDrawInfo: (Cell)
 copyFromZone: (ButtonCell)
 free (ButtonCell)
 ...and the state 0 (icon/image) and state 1 (altIcon/altImage)
 methods.

and, of course, you'll need some ways to get the additional icons
in there and to access them.  Even though there's a lot listed
here, most of the code is trivial.

>Unfortunately, when I subclass a ButtonCell, I couldn't figure out
>how to instantiate the subclass under IB.  It didn't appear in the
>class panel or under the custom view panel (Not a surprise).

Cells aren't subclasses of View.

>Anyway, any help on how to instantiate the new subclass would be
>appreciated.  (Or do I have to reclass a Button created with IB?)

Although it's convenient to think of Button as a single object,
it's really two: when you create a Button, you also get a
ButtonCell at the same time.  This sort of "pairing" occurs in
other NeXTstep classes as well--e.g., Windows come with a View
(contentView), a bunch of things come with Lists, etc.

For the "simple" Cells, there is a corresponding "simple" Control
subclass that offers both Control methods *and* Cell methods--
this means that your program doesn't have to understand the
distinction; it can send everything to one place, and the Cell
stuff will just be sent to the associated Cell object so you
don't need to ask for cell or selectedCell all the time.  Button
is arguably a convenience; you could just as well use ButtonCell
with some other Control; for example, a 1x1 Matrix.  (This can be
useful in practice, as Matrix can do things Button cannot, such
as handle double-clicks.)

Why might you want to subclass Button as well as ButtonCell?
One reason might be that you were developing something for
reuse.  It would be a "convincing" replacement, too, responding
favorably to queries like isKindOf:[Button class].

As for using ButtonCell subclasses with IB-created Buttons,
that's not terribly difficult.  One thing I would not use is
setCellClass:--that would turn ALL Buttons into mutant Buttons.
Instead, I'd have an outlet method use setCell: to replace the
original ButtonCell, transfer the instance variables (this CAN be
tricky, since you don't want to inadvertently set yourself up to
free something twice), and free the ButtonCell.  Of course, you
won't be able to use IB's Test Interface facility this way--if
you want that, make a loadable IB palette.

					-=EPS=-