Pierre Zippi wrote:

> I wrote:
> > A quick comment about the last part of your code. Be sure to check for errors
> > after the call to CHANGEDRESOURCE. I've been a little cavalier on occasion about
> > this, but a recent experience shows how important it can be.
> >
> > I'm doing a number of projects for CD-ROM and, in order to check some features
> > while on my hard drive, I have to simulate their being on CD by locking them.
> > Well, you can't write to your Resources when the app is locked; so, if you try to
> > do so and you have not provided an error check for this you can have some
> > mysterious problems crop up. You probably ought to do the same following the call
> > to ADDRESOURCE.

> What would you use to check for errors?

Hi Pierre,

Here's a portion of a FN I use: (some VARs are DIMmed earlier.

LONG IF gIsOnCD% = _true
  ' We try to write to a resource. If it is on the CD ROM, we can't do
  ' it; so we know they are trying to use a copy if it is successful.
  DIM R%
  DIM H&
  DIM M$
  H& = FN GETRESOURCE(_"STR#",2003)
  LONG IF H& <> 0
    OSErr% = FN HNOPURGE(H&)
    IF OSErr% THEN END
    DEF APNDSTR("Yuk",H&)
    CALL CHANGEDRESOURCE(H&)
    OSErr% = FN RESERROR
    LONG IF OSErr% = 0
      M$ =      "Sorry, you may ONLY Play "
      M$ = M$ + "from your CD ROM; Remove "
      M$ = M$ + "the Copy from your Hard "
      M$ = M$ + "Drive.     God Bless You!"
      CALL PARAMTEXT (M$,"","","")
      R% = FN ALERT (129,0)
      END
    END IF
  END IF
  LONG IF FVRN% = 0                               'Do Registration
    gRegPlayerName$ = ""
    gRegPlayerBD$ = ""
    gRegPlayerRegNo$ = ""
    gRegistered% = _false
  XELSE
    gRegistered% = _true
  END IF
XELSE    REM Download Version is on the Hard Drive
'Other stuff here.
END IF

When you use Toolbox Routines it is always a good idea to look them up in IM, where
you will usually find some sort of error checking recommendation. Several of the C++
Books for the Macintosh discuss error checking at length.

This shows two situations, in both cases of which I choose to terminate the program;
but, in many instances, you want to put something in the Alert that is displayed that
tells you where the problem will be found in your code; hence the use of numbers
instead of descriptions in many cases. In other words, one of the reasons that a
meaningful error code is not inserted is because the programmer anticipates that
he/she will be the one to find the error - not some "stupid" user.

Hope this helps a bit,

Joe Wilkins