In Association with Amazon.com
Palm OS® Programming For Dummies® Corrections

CodeWarrior Lite Install problem
Chapter 6, bad cross reference to GDB in Chapter 21
Chapter 6, missing example file
Chapter 9, Does SimplePin Example Work?

CodeWarrior Lite Install problem 


A reader had a problem with the example on page 30 that was related to Code Warrior Lite. It seems that CW Lite may not correctly associate the file types for resource files (.rsrc)

Sometimes when you install CW Lite, the correct file associations are not made in Windows, and then the correct tools won't launch.

You can fix this by right clicking on any .rscs file, and then choose Open With... In the dialog box that appears, check the "Always use this program to open this file" checkbox on the bottom, and then click Other... Browse to "Constructor for Palm OS.exe" in the Code Warrior Bin folder (usually 
C:/Program Files/Metrowerks/Codewarrior/Bin/Constructor for Palm OS.exe) and select this file. Then click Open. The click Ok in the dialog window. This should correct the problem.
 

Chapter 6, bad cross reference to GDB in Chapter 21 

At the end of chapter 6, page 104, we mention that we will discuss using the gdb debugger in chapter 21.

Yes, you've found an editing error in the book... when we moved the
three chapters to the CD, this reference was missed. It should point
you to the debugging chapter (Chapter 16). Gdb is covered starting on
page 323.
 

The TOC has the correct info (Page xx) and the index has several listings for gdb.
Sorry for the slip, we'll correct it in the next printing.
 

Chapter 6, bad cross reference to GDB in Chapter 21 

On page 103, under the heading "Making the makefile", we point you to an example makefile on the CD-ROM. You've no doubt noticed that it's not on the CD-ROM. You can use the makefile in the Chap08/Src/ directory, or use this link: Example Makefile
 

Chapter 9, Does SimplePin Example Work?

I intorduced a bug in the example during the final review of the book.
The fix for Chapter 9 is to add one line to the InitOverviewForm() function:
static void InitOverviewForm() {
 ListPtr lstPtr;
 int i;
 for ( i = 0; i < 10; i++)
  listValPtrs[i] = prefs.PinDetail[i].Name;
 lstPtr = (ListPtr)GetObjectPtr(Overview_PinList);
 LstSetListChoices(lstPtr, listValPtrs, 10);
 LstSetSelection(lstPtr, -1);
 prefs.editPinNo = -1;
 LstDrawList(lstPtr);
#ifdef NO_ALERT_ON_FULL
 InitOverviewFormMenu();
#endif
}


The new line is LstDrawList(lstPrt);

The problem I was correcting when I introduced this bug is that it's considered "bad form" to initialize a form's elements before you draw the form when it is first opened, as in the OverviewFormHandleEvent()function:
 

 case frmOpenEvent: // initialize overview list
  FrmDrawForm (FrmGetActiveForm());
  InitOverviewForm();
  handled = true;
  break;


I had incorrectly called the InitOverviewForm() function before drawing the form. This meant I didn't need to call LstDrawList() after I changed the list, since it would get drawn when the form was drawn. Since I reversed the order of the calls, I must include the LstDrawList() call in the init function, to redraw the list.