John
Tue Oct 12 07:58:10 CDT 2004
Hi Peter,
Thanks for the info about latin and cero. I ended up using chrW and ascW to
properly use ascii codes 128-255 in strings on cero-based devices.
I want to send you an email and instructions how to obtain a free copy for
one of my products as thanks, but your email address in your posts is
invalid (probably for spam reasons). How can I obtain you email address to
send you the info?
-John Cody
"Peter" <no_reply@mail.company.com> wrote in message
news:%23QOMpUBrEHA.536@TK2MSFTNGP11.phx.gbl...
> Your problem seems to be related to the fact that unicode characters use
two
> bytes to represent a character, oposed to usual one byte per character,
> basic latin characters use only one byte in unicode, the other is cero,
this
> is why your program works with English locale, but other languajes use
both
> bytes.
>
> If tou are programing in VB or VB.net try using a string variable that
uses
> unicode, I program in eVC, and use CString data type which supports
unicode.
>
> For more information about unicode visit
http://www.unicode.org
>
> Peter
>
> "John Cody" <newsgroups@noospammmax-soft.com> wrote in message
> news:ekrPef6qEHA.3520@TK2MSFTNGP11.phx.gbl...
> > Hi Peter,
> >
> > Thanks for taking the time to respond :)
> >
> > Yeah, as I mentioned in my post, I thought it has something to do with
> > Unicode, but I am just not sure exactly what...
> >
> > I am now thinking that codes 128-255 in a Chinese "locale" (character
> set?)
> > have redundant (the same) characters in there, so it's not reliable to
> build
> > a string of characters from those codes, if the codes need to be
> > re-extractable using asc(mid(x,x,1)).
> >
> > -John Cody
> >
> > "Peter" <no_reply@mail.company.com> wrote in message
> > news:eAoTcKoqEHA.1272@TK2MSFTNGP09.phx.gbl...
> > > Remember that pocket pc devices use UNICODE
> > >
> > > Peter
> > >
> > > "John Cody" <newsgroups@noospammmax-soft.com> wrote in message
> > > news:O4mLojiqEHA.2588@TK2MSFTNGP12.phx.gbl...
> > > > Hi,
> > > >
> > > > I have a real stumper of an issue...I am creating a string,
character
> > by
> > > > character by doing a:
> > > >
> > > > Do
> > > > S = S & CHR(X)
> > > > Loop while ....
> > > >
> > > > The value of X will randomly vary from 0 to 255 (FF). And, with my
> > > > Smartphone's "Locale" setting to "English", the string is built of
the
> > > > proper individual characters representing the specified values for
X.
> > > >
> > > > But, if a user's Smartphone has their "Locale" set to "Chinese", the
> > CHR()
> > > > function doesn't appear to create the proper characters for X values
> > above
> > > > 127 (highest ANSI code). For example, if the sequential values of X
> are
> > > 237,
> > > > 207, 45.....if I then loop through the string and read the ASC() of
> each
> > > > individual character, I will get 31, 31, 45 when the "Locale" is
> > Chinese.
> > > If
> > > > I instead use CHRB(x), then the resulting ASC() values will be
> 169,169,
> > 45
> > > > for a "Chinese" locale (NOTE: using the alternate chrb() method
still
> > > works
> > > > fine on "English" locales)
> > > >
> > > > I'm thinking that this is related to some Unicode issue, and that
the
> > > > characters representing codes 128-255 are invalid for a Chinese
> > "locale".
> > > > But, this is just a guess.
> > > >
> > > > This is a real-pain of an issue to fix because I can not reproduce
the
> > > > error - I have to keep "bugging" a [very helpful] Hong Kong user to
> test
> > > > different trace/debug versions on their "Chinese" local phone to see
> if
> > it
> > > > fixes the issue, but this is not fair to them...
> > > >
> > > > So, I am offering a reward of a FREE copy for one of my products:
> > > >
> > > >
http://www.omnisoft.com/products.asp
> > > >
> > > > For anyone who first posts the solution to this issue...
> > > >
> > > > Thanks a bunch!
> > > >
> > > > -John Cody
> > > >
> > > >
> > >
> > >
> >
> >
>
>