Errata

see code on page 333

Looking further, the problem is that the line path=[[NSBundle mainBundle] pathForAuxiliaryExecutable=@"Evaluator"]; in windowDidLoad fails to work and returns null. That explains the error message triggered by setLaunchPath a few lines later. A workaround is to hardcode the path as an NSString.

I am not yet clear why pathForAuxiliaryExecutable fails to work.

I got the same problem. Using old-fashioned debugging with printf I found the problem was the line [evaluator setLaunchPath:path]; in windowDidLoad in PaperController.m

There seem to be many problems with this diagram.

(i) ATTENDEES table shouldn't have a USER_TYPE_ID field
(ii) ATTENDEES table should link to USERS table, not USER_TYPES

This is a difficult exercise to accomplish. I have always wondered if Apple's
implementation of services is buggy, or if particular apps don't handle
services.

For example, I can do Services:Grab:Selection in TextEdit, but not in Internet
Explorer. It would seem that only Apple Apps can be a client to services.
Can you show me a non-Apple App that can be a service client?

Obviously some services are context sensitive and require user action such as
highlighting text before using them.
**[59] Ex. 4;**
Oh, I get it. Services only work with Cocoa apps.

While it is interesting to see gdb running in Emacs, Emacs itself is not introduced
until page 108 and is very difficult for a novice to use. The introduction on page
108 should be moved to chapter 2 and a few Emacs commands mentioned; specifically,
how to get help and how to quit the program.

The text says that a "class interface" is "a fancy name for an included
file that is brought to the compiler's attention with an #import directive,"
but the example which follows shows an import directive and a separate
class interface. This is confusing because the import directive in the
example is not explained. I think what is meant is that the example file,
which contains a class interface, will be brought to the compiler's attention
with an import directive in some other file. Then explain the import
directive in the example.

The code as given can lead to serious memory problems, and provoke an
application crash. This problem can happen if the object passed as
parameter to the methods is the same as the instance variable object.

The more correct approaching pattern (there are other solutions) is:

- (void) setStart:(id) anObject
{
[start autorelease];
start = [anObject retain];
}

I am not sure if this is a technical mistake or not..

But in the over ridden -(void)dealloc routine, shouldn't
the last action call be to

[super dealloc]

and NOT
[super release]

It makes no sense to override the dealloc routine and then
call the parent's release routine to finish doing the
dealloc work..

so.. I think the proper code should be

-(void)dealloc
{
[start release] ;
[end release] ;
[super dealloc] ;
}

The implementation of the two set methods shown does not work in some
special cases and will cause an application to show unpredictable results
depending on its use.

Precisely, the set methods do not work, if the argument passed in has
the same value as the instance variable (e.g. start) and the retain count
of the object referenced is one.

i.e. (start==anobject && [start retainCount]==1) yields YES.

What happens it that the start object is destroyed using -dealloc and retain is
called on that freed memory region.

The appendString: calls are missing the @ signs before the double-quotes.
It should read:

[str3 appendString:@"This is how you build "];
[str3 appendString:@"a Cocoa String"];

Without the @ signs this will generate a compiler error

This one is related to the one on page 123:

i.e. (start==anobject && [start retainCount]==1) yields YES.

What happens it that the start object is destroyed using -dealloc and
retain is called on that freed memory region.

The sentence in the box ought to be some mantra to always remember.
However, it is inacurate, as "accessor method" means both set- and
get- methods. In order to be correct, it should say "set-methods"
or "setters".

The text reads: "The event loop terminates when the NSApp object is
sent an NSApp or stop: message; this usually happens when the user
chooses the Quit menu command. The NSApp message causes NSApp to call
exit(), terminating the program. The stop: message causes [NSApp run]
to exit."

The first message should not be NSApp but rather terminate:. Thus the
text should read: "The event loop terminates when the NSApp object is
sent a terminate: or stop: message; this usually happens when the user
chooses the Quit menu command. The terminate: message causes NSApp to
call exit(), terminating the program. The stop: message causes [NSApp run]
to exit."

incorrect capitilisation of methods, should read:

14. Add the clearAll:, enterDigit:,

not

14. Add the clearall:, enterdigit:,

One of the important things programmers do is name things. The instance variables in
Calculator are poorly named. 'X' and 'Y' are uppercase, against social norms. They
would be better named 'operand' and 'total'. 'enterFlag' and 'yFlag' are named a bit
vague. Once you name things for what they do, you see how the algorithm is really
working. For example, the assignment Y = X; in enterDigit is redundant: it's always
going to have happened already in enterOp.

After renaming and tracing, I just had to rewrite the algorithm:

- (IBAction)clearAll:(id)sender
{
operand = total = 0.0;
operator = NONE; //(add this to enum and lose yFlag)
operandEntryToBeginFlag = YES; //enterFlag renamed
[self displayOperand];
}

- (IBAction)enterDigit:(id)sender
{
if (operandEntryToBeginFlag)
{
operand = 0.0;
operandEntryToBeginFlag = NO; //operand entry now begun
}

operand = (operand >= 0 ?
(operand * radix) + [[sender selectedCell] tag] :
(operand * radix) - [[sender selectedCell] tag]);
[self displayOperand];
}

- (IBAction)enterOperator:(id)sender
{

switch (operator)
{
case NONE: total = operand; break;
case ADD: operand = total += operand; break;
case SUBTRACT: operand = total -= operand; break;
case MULTIPLY: operand = total *= operand; break;
case DIVIDE: operand = total /= operand; break;
case EQUALS: total = operand; break;
default: //should never reach here
NSLog(@"Error: reached switch default in enterOperator");
[readout setStringValue: [NSString stringWithFormat: @"improper
operator"]];
return;
}
operator = [[sender selectedCell] tag]; //get the next operation

operandEntryToBeginFlag = YES; //ready to start entering the next operand

[self displayOperand]; //display the total (same as the operand for the moment)
}

return self;

not consistent with same code on pp 161 where function exits after
[self display]

When you implement doUnaryMinus, you must modify one line of enterDigit:

X = (X >= 0 ?
(X * radix) + [[sender selectedCell] tag] :
(X * radix) - [[sender selectedCell] tag]);

Otherwise, the user may change the sign to minus and continue entering the operand
and the calculator will malfuntion.

Here's what you get for running out and buying Jaguar before these fine authors could
revise their book:

Bring up the File's Owner information as decribed in the text. Here's where we start
to deviate from the text. The way to inform File'sOwner that is of the Controller is
by finding it under the Custom Class screen not the Attributes screen of the File's
Owner Info dialog. Follow the instructions in the book to make AboutPanel.nib of the
Controller class. Just do not go by Figure 6-16. I compiled and it worked.

Oh, where to begin? This section about images really needs clarification,
perhaps a whole page. The text says to drop an image file in "a nib
window in IB or in the main window in PB." Are the results of those two
actions identical, or are they entirely different? The following sentence
seems to indicate that they are different ("images that are stored in one
nib cannot easily be used by objects in other nibs"), yet when dragging an
image to one nib window the image is accessible in the other nib (under
its Images tab). Also, when dragging an image to a nib, a dialog appears
asking if the image should be added to the project. So, it appears that
the two actions are the same. (I'm using PB 1.1.1 and IB 2.2.)

Also, it appears that dropping an image file in PB only leaves a reference
(alias?) because deleting the image in the groups window of PB asks about d
eleting the reference. What happens then if the original image file is
moved or altered?

Images appear to be stored in the project folder. Where are the sounds,
where'd they come from?

How to delete (unused) images or sounds from a nib? Should we?

The text says to drop an image "in the main window in PB." What is the
main window? I find that an image can only be dropped in the "Groups
and Files" window, and even then the user must drag it in to desired
location within the list of files. (PB 1.1.1.)

In the first sentence:

"To make the Controller work with this new NSMatrix that contains a
pop-up menu, ..."

Do you really mean to say 'NSMatrix', or did you mean to say 'NSButton'.
We haven't added an NSMatrix to the application since adding the function
buttons; but we have just added a pop-up menu, and that is a type of NSButton.

This section would benefit by a diagram showing how objects delegate messages and
which object talks to which other objects, etc. In general, the entire book would be
better if there were a few diagrams showing how object and windows relate, how
actions and outlets operate, etc.

The direction of the connection seems counter-intuitive since the information flow
(the initial value of the popup) is from the popup to the Controller. I guess
"information flow" is the wrong way to think about this (aren't we dealing with
references here?), but I lack the mental image of how this works. Please explain
further in the text.

"Refer to the Cocoa Foundation documentation." This is not the first place this
phrase appears. A brief description of how to navigate in PB to the documentation
based on a highlighted selection in the code would be useful.

I'm repeating myself here, but the discussions of keyboard events and event chains in
general (in addition to objects and messages) just cry out for some diagrams. For
example, look at pages 224 and 225 in Aaron Hillengass's "Cocoa Programming for Mac
OS X".

In checkView, I believe there is a more straightforward way (and indeed, a more
robust way in this case) to test the class, as follows:
if ( [aView isKindOfClass: [NSMatrix class] ] ) {
could be simplified to:
if ( [aView class] == [NSMatrix class] ) {

and on page 270:
if ( [aView isKindOfClass: [NSButton class] ] ) {
easier:
if ( [aView class] == [NSButton class] ) {
If my logic is not equivalent or better, then the text could explain why.

If you want to investigate special characters (delete key, enter, etc.) put this in
your keyDown method:

NSLog([theEvent characters]);

Also, see NSEvent.h.

Then implement them in your checkButton method:

if (@selector(clearAll:) == [aButton action])
{
//clear key (note capital %C for unicode!)
[keyPressTable setObject: aButton
forKey: [NSString stringWithFormat: @"%C",
NSClearLineFunctionKey]];
//delete key
[keyPressTable setObject: aButton
forKey: [NSString stringWithFormat: @"177"]];

//escape key
[keyPressTable setObject: aButton
forKey: [NSString stringWithFormat: @"33"]];

} else if ([title isEqualToString: @"="])
{
//enter key for equals
[keyPressTable setObject: aButton
forKey: [NSString stringWithFormat: @"03"]];

//return key for equals
[keyPressTable setObject: aButton
forKey: [NSString stringWithFormat: @" "]];

//equals for equals
[keyPressTable setObject: aButton forKey: title];

} else if ([title isEqualToString: @"w"])
{
//option forward slash for division (change your nib to w)
[keyPressTable setObject: aButton forKey: title];

//forward slash for division
[keyPressTable setObject: aButton
forKey: [NSString stringWithFormat: @"/"]];

} else if (1 == [title length] && [aButton isEnabled])
{
[keyPressTable setObject: aButton forKey: [title uppercaseString]];
[keyPressTable setObject: aButton forKey: [title lowercaseString]];
}

In addition to the errors in the Calculator code itself (that are fixed in the
exercises), there appears to be some errors in the nibs (indicated by the little
yellow "!" attached to the instances icons). In my case, the "MainMenu" instance of
MainMenu.nib shows "One of the children has a bad/missing connection") and the
"File's Owner" instance in both nibs show "unconnected outlet".

Suggestion. Other good exercises would be to program the Delete key to delete the
least-significant digit from the calculator display and the Return key to perform the
"=" function. Also, how about adding an RPN mode?

My PB is 2.0.1

the command:

[NSBundle mainBundle] pathForAuxiliaryExecutable: @"Evaluator"

look at Contents folder (that is build/MathPaper.app/Contents in our example}

>From PB I cannot move to Contents folder of product. No bar line shown up

It may be PB2.0.1 change the GUI layout, I I cannot find "New Build Phase -> New Copy
Files Build Phase command"

(see also unofficial errata dated 5/22/2002:

Another way to get lastLine with two lines of code:

NSArray *paragraphs = [[theText string] componentsSeparatedByString: @"
"];
NSString *lastLine = [paragraphs objectAtIndex: [paragraphs count] - 2];

While this may not really qualify as Errata, I found the following problem:

After succcessful compilation the program failed to show any document windows,
reporting

2006-11-05 18:40:16.290 MathPaper[10718] *** -[NSCFDictionary setObject:forKey:]:
attempt to insert nil value

in the Run Log window.

The same happened with the code downloaded from the web site so I will assume some
incompatibility with newer versions of XCode (I am running 2.4 right now).

As I just started Cocoa programming using this book I feel unable yet to figure out
what might have gone wrong and would appreciate any hints on how to proceed ...

Using old-fashioned debugging with printf I found the problem was the line [evaluator setLaunchPath:path]; in windowDidLoad in PaperController.m

see code on page 333

Looking further, the problem is that the line path=[[NSBundle mainBundle] pathForAuxiliaryExecutable=@"Evaluator"]; in windowDidLoad fails to work and returns null. That explains the error message triggered by setLaunchPath a few lines later. A workaround is to hardcode the path as an NSString.

I am not yet clear why pathForAuxiliaryExecutable fails to work.

In order to avoid memory leakage, data2 shoud be autoreleased.

Thus, the last line should be:

return [data2 autorelease];

All three #import statements should not have a semicolon at the end, and the file
names should be surrounded with double quotes.

#import "PaperController.h"
#import "RTF.h"
#import "MathDocument.h"

With the current Project Builder, the default File->Print command sends
printDocument:, not print: to the first responder object. The NSTextView doesn't
respond to print: so nothing happens when you select Print. You can either change the
action of the Print item to print: or override printDocument: in MathDocument.m:

- (IBAction) printDocument:(id)sender
{
[[self windowControllers] makeObjectsPerformSelector:@selector(print)];
}

Then you need to add a method to the PaperController object:

- (void) print
{
[theText print:self];
}

I am using the new April 2002 Dev tool set, and in this
version to change the class for File's Owner, it is located
under the general attributes section of the info panel,
i.e. Command-1 and not Command-5. This may change again
in the production release..

Despite having the user try to "add the takePercentage: action method to the BarView
class in the BarView Class inspector", and mentioning that one "cannot select the
rectangular BarView instance in the window to add outlets or actions", BarView is not
listed under the "instances" tab. One can either connect to the "Window" instance
(which will bring up the choice to choose the right action), or, contrary to the
warning, control-drag directly to the BarView instance in the window and then connect
the right action. At least for a beginner, this was a confusing subtlety maybe worth
a tiny screenshot.

Steps 5 & 6 describe a multiple selection of files "grammar.y" followed by "rules.l"
from the finder and then dragging them into PB's Resources group. When I followed
these instructions explicitly I later got an error when I tried to compile, in step
8. The error something to the effect that a a file was missing.

The fix is to drag the two files from the finder separately. Refer to page 325,
indented paragraph, first sentence.

"It is important that you add grammar.y before you load rules.l ..."

It might also be helpful to mention that the instructions for building GraphPaper
using the Evaluator are somewhat different than building MathPaper, which also uses
the Evaluator. perhaps the difference is because MathPaper is document-based.

an error in the code, left out a third set of brackets:

evaluator = [[NSTask alloc] init] retain;
[evaluator setLaunchPath:path];

should be:

evaluator = [[[NSTask alloc] init] retain];
[evaluator setLaunchPath:path];

sendData works when called normally without an argument (i.e., [self sendData];).
However, it cannot be detached as a thread, using Dec. 2002 Developer Tools, unless
it is declared as - (void)sendData:(id)arg. arg does not have to be used in sendData,
but the program does not work as printed--an exception is immediately raised that
there is no autorelease pool. Adding an argument to the declaration of sendData
immediately fixes the problem.

Step 10 omits an ";"

- (void)dealloc
{
[dict release]
[text release];
[super dealloc];
}

should be:

- (void)dealloc
{
[dict release];
[text release];
[super dealloc];
}

I have been building this project somewhat differently than the book describes. I
have been saving the generated curve directly into a Bezier curve. Then rather than
scale the view down to the bounds of the graph I scale the Bezier curve up to the
coordinates of the view and draw with a 1 pixel pen.

Done this way the lines do not require scaling to draw them. A 1 pixel line is stil
one pixel no matter how the image is scaled and is symmetric.

Further, as the image is in screen coordinates rather than Bezier curve coordinates
the print to PDF problems described on p 523 do not occur. The image prints properly
to a pdf without the need of a temporary window p525, section 6.

In the message implementation for setFormat in Controller,
the first line "savePanel = [NSSavePanel savePanel];" should be eliminated,
and in fact has been in the downloadable code. If you use the code as printed in the
book, it changes the format on a newly created panel, not the one attached to the
window, and thus you can only ever create PDF files.

"Change some colors and click the Revert button; notice how the original colors
return to the Preferences panel."

I have followed the instructions in the chapter, however my Revert button doesn't
revert the color wells to their original colors. I downloaded and built the
corresponding example program from your ftp site, but it does not appear to work
either.