> Give us the standard function names where applicable, "strcat"
> instead of "StrCat", "memset" instead of "MemSet", etc.

but what if you really do want to use the MSL version, and not the OS
version?  (i certainly agree that the parameter order should not have been
changed, though!!).  but it's so easy to write a couple macros and just be
done with it.  heck, someone can even post a header with the macros
predefined (similar to the callback.h header used by just about everyone
using GCC).  there are many larger, more important issues, and personally it
seems like a waste to have Palm address this particular one instead of
spending the time on some more critical issue such as unique ids.

#define memset(pv, value, size) MemSet(pv, size, value)
#define strcat(pDest, pSrc) StrCat(pDest, pSrc)
#define strcpy(pDest, pSrc) StrCopy(pDest, pSrc)


> All the places in the API that are supposed to return
> error codes but instead pop up their own "reset" dialog.
> (I think that some, but not all, of these have been
> addressed already...)

you mean the ones that are documented to return a particular code but reset
anyway, right?  it's common knowledge that "there's still a couple broken
APIs", but does anyone know which APIs are still broken?  all the ones i use
are fine.

in general it's very good for users that the OS forces a reset instead of
letting the buggy app continue to run.  for developers, during the
development process, it's not so fun but the best way to deal with that is
to have a special debug ROM that returns the error codes.  but heck, POSE
already supports that, with its Continue button.


Reply via email to