Rick,
>I'm trying to fix a reported bug when my program is run on an IBM
>Workpad Japanese version. It is trying to use FindStrInStr
>to find a text string. First, it converts the string using the
>GetCharCaselessValue() offset table, then passes it to FindStrInStr().
>This seems to work well in the US, but on the Japanese device, and
>also on the Emulator with the Japanese ROM FindStrInStr fails to return
>the correct result.
>
>Is there a different offset table I should use in Japan, or something?
>And if so, how does my program figure out what country it's in?
and
>OK, I'm getting a little closer, for all of you waiting anxiously
>for the answer to this problem. When my app responds to a
>global Search command to find the word "the", using the US
>ROM, the strToFind parameter of the FindParams looks something like
>"oO+", or some such garbage, three letters long. But if I simply
>change to the Japanese ROM and search for the same word "the",
>my program gets a strToFind like "CiCaCO", with little tails
>from the Cs, and accents on top of the i, a, and O. So somehow
>the OS is changing a three character search string into six
>bytes. I bet this has to do with Japanese unicodes, or something.
>
>So to solve my problem, I just need to know how to convert a
>English one-byte character stringAsTyped into a Japanese two-byte
>(CharCaselessValue) strToFind.
>Can anybody tell me how to do this??????
1. The process by which the find code generates a search string isn't
guaranteed to always be the same (as you found out). FindStrInStr() assumes
that it is getting passed a target string which has been properly prepared
by the find code.
2. There's a new routine in Palm OS 3.1 (and later) which does what you
want, called TxtPrepFindString. So your code should default to what it
currently does on older roms, and use this new routine on 3.1 and later.
Another option is to call the TxtGluePrepFindString routine, which will be
available in the 3.1 SDK (see comment below).
3. Note that to really work correctly with Japanese, you need to call the
TxtFindString routine:
Boolean TxtFindString(const Char* inSourceStr, const Char* inTargetStr,
UInt32 * outPos, UInt16 * outLength);
It's basically the same as FindStrInStr, except that it returns a long
(UInt32) offset, and it also gives you the amount of text (number of bytes)
that it matched in the source string.
This second value is the interesting one for multi-byte languages such as
Japanese. Potentially the user could be searching for the word "the", and
wind up matching the equivalent word comprised of three double-byte romaji
characters (Japanese search is character-size insensitive, as well as
case-insensitive). Or the inverse situation could also happen.
The best way to save this match length result is to pass it as the
<appCustom> parameter to FindSaveMatch(). Then when you get the
sysAppLaunchCmdGoto launch code, the GoToParamsType. matchCustom field will
contain this value, which you use to select the appropriate # of bytes in
the field.
4. Note that when the 3.1 SDK finally goes out the door, there will be a
glue library with a TxtGlueFindString routine, which you can safely call on
any version of the OS >= 2.0. All of the TxtGlueXXX routines default to
appropriate PalmLatin behavior on older roms, since there was no support
for other character encodings before 3.1 shipped.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200 (direct) +1 408-261-7550 (main)
