> -----Original Message-----
> From: Chris Antos [mailto:[EMAIL PROTECTED]]
>
> > Give us the standard function names where applicable, "strcat"
> > instead of "StrCat", "memset" instead of "MemSet", etc.
...
> 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.
Well, now that it's been done, perhaps ... but wasn't
it quite a waste of their time to come up with this alternate
set of functions in the first place?
> > 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.
Not if the documentation says it returns an error code.
If they want a system function to crash & burn if anything
goes wrong instead of sending a code back to the caller to
handle as the caller deems appropriate, at the very least they
should be documented that way:
this function dies a horrible flaming death if
anything goes wrong.
better still: an OS-level flag for "protection level".
If the program doesn't want to take responsibility for
protection, let the OS put up the reset dialogs when
things go wrong, but if the app -does- want to handle
things differently, it should have the option to do so.
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi./sec ... not just a good idea, it's the LAW!
