> 1. The target (string to search for) string that's passed to FindStrInStr
> is typically a munged version of the string that the user entered in the
> Find form. The FindStrInStr routine, as well as the newer TxtFindString
> routine, _require_ that this string be converted into the appropriate
> format.
read the OS3 source code. your explanation does NOT match the source code.
(i am talking about FindStrInStr, i have not looked at TxtFindString, but i
bet the same applies there).
empirical evidence over here suggests that OS2 doesn't work like that
either.
for me, OS2 correctly finds "XyZzY" when i search for "XYZ".
> What FindStrInStr/TxtFindString _will_ do for you is dynamically convert
> the text that is being searched (for FindStrInStr, that's the strToSearch
> param) into this same munged format for comparison purposes.
well, effectively. it doesn't actually convert the string, it just uses the
characters in the string as indices into the GetCaselessSortValue table and
then compares those values.
> 2. Bozidar's response was correct for the _current_ implementation of the
> _Latin_ version of the Palm OS. It will not work for non-Latin versions
> (e.g. Japanese), and it might not work in the future.
i don't know how GetCaselessSortValue is implemented on non-Latin versions,
so i can't speak to that. but from looking at the source, Bozidar's
suggestion is purely placebo and does not affect the execution AT ALL, at
least not on OS3. from looking at the source, i seriously doubt that Palm
is going to screw it up for non-Latin as you imply.
> Also note that if strAsTyped (in his example) is a Char*, then his code
> snippet would fail for characters in the high ascii range, as they would
be
> treated as signed values, and thus generate negative indexes into the
> conversion table.
uh, how did you determine that??
wrong. read the source. it doesn't depend on the type you're passing it,
it depends on the types inside the function. and inside the function,
everything is of type Byte. no signed problems there!
like i said, maybe you are going from pre-OS3. but i'm looking at the OS3
source and it does not match your explanation. and my tests on OS2 don't
match this explanation either. it finds "XyZzY" where the first "y" has a
diaeresis (umlaut) works just fine when i search for "XYZ" where the "Y" has
a diaeresis. both the Y-diaeresis and the y-diaeresis characters have the
high bit set.
> 3. Currently there is no good solution to correctly generating the
> appropriately munged target string yourself. Soon there will be a glue
> routine that can be used to do this correctly for 2.0 and later versions
of
> Palm OS.
this explanation is totally contrary to the OS3 source code. i'm not having
any of these problems, even when using high-bit characters, etc. and i've
tested this on OS2 as well. so maybe this is an archaic OS1 issue???
