Re: Cocoa Documentation on NSFormatter
Re: Cocoa Documentation on NSFormatter
- Subject: Re: Cocoa Documentation on NSFormatter
- From: Vince DeMarco <email@hidden>
- Date: Sun, 16 Dec 2001 12:50:52 -0800
On Sunday, December 16, 2001, at 01:40 am, Thomas Lachand-Robert wrote:
Le dimanche 16 dicembre 2001, ` 03:23 , Vince DeMarco a icrit :
There is an example on the system of exactly this (A subclass of
NSFormatter that parses math expressions) look in
/Developer/Examples/InterfaceBuilder/BusyPalette
Thanks for the indication, I didn't see that example (maybe because the
name 'busyPalette' makes so obvious that there is an expression formatter
here ;-)). My formatter does not do that though: much more complicated
expressions (with math functions, with variables and constants, with
complex numbers) are considered. Also the expression is parsed, but not
replaced by its computed value: it is intended to be used somewhere else.
This is why you should spend some time and look at all of the examples on
the system. They all cover alot of stuff there.
I don't understand sme point in their code, though. The readme says:
The main requirement Interface Builder has of a widget is that it
implements the NSCoding protocol (initWithCoder: and encodeWithCoder).
In the case of ExpressionFormatter and ExpressionEvaluator archiving was
not necessary because:
ExpressionEvaluator has no state and thus doesn't need to archive
anything.
Ok but ExpressionEvaluator doesn't even declare NSCoding nor its methods,
which means that IB cannot even call initWithCoder on it? So probably IB
can actually accept widget that doesn't implement NSCoding protocol,
assuming that if they don't, they have nothing to encode? The sentence
seems misleading, if this is true.
Its superclass does all of the real work. The subclass just lets you enter
the expression then its passed to the superclass.
vince