> -----Original Message-----
> From: Scott Johnson [mailto:[EMAIL PROTECTED]]
>
> Ion Popescu wrote:
> > Wouldn't it be easier to define StrChr as StrChr(char *,
> char/UChar)
> > rather than StrChr(char *, Int)?
>
> See the 3.1 docs at <http://www.palm.com/devzone/docs.html> especially
> the Localized Applications chapter in the Companion book.
> Basically 3.1
> now supports multi-byte characters (on certain devices) so the 16-bit
> 2nd argument to StrChr is correct. There is a new data type called
> WChar (16 bits) for this purpose.
>
This is one place where MSoft got it right. They have
a macro (TCHAR) that expands into the proper basic type
depending upon whether you've set the option for single
byte or multibyte support. Different libraries are
linked in depending upon the setting.
For those of -not- using "certain devices", who only
need the single-byte character support, we shouldn't
have to pay the overhead of library routines built
for multi-byte support. Nor should we have to deal
w/ the issues like this where "char" would be the
proper type.
The prototype for StrChr should be:
StrChr(XCHAR *, XCHAR)
I didn't suggest actually ising "TCHAR" because MSoft
may have a copyright or something ... nonetheless, a
header file could set up these definitions and the code
wouldn't have to care so much:
#if MULTIBYTE_SUPPORT
#define StrCpy mbStrCpy
#define XCHAR int
#else
#define StrCpy strcpy
#define XCHAR char
#endif
btw: is there any real reason that "StrCpy" is being
used by the Palm libraries instead of the standard
name, "strcpy"?
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi./sec ... not just a good idea, it's the LAW!
