Holger Klawitter said:
>Hi there,
>
>I am wondering about the FindStrInStr function. When debugging my
>Search function, the following strings are being passed to FinStrInStr:
> rec "123456789" (pointer to DB)
> pattern "1234"
> &pos 0
>Unfortunately FindStrInStr returns FALSE.
>
>Another thing: The strToSearch seems to be totaly wrong when peeking
>into the FindParams structure - strAsTyped is ok. I don't think it's
>the emulator (d29 FYI) because on the real device Search also
>yields no match. With FindHack, however, the program crashes.
>
>Any clue?
Bozidar Benc replied:
>You must convert the actual string (strAsTyped):
>
>BytePtr convTab = GetCharCaselessValue();
>
>for (z=0; strAsTyped[z] != 0; z++)
> strToSearch[z] = convTab[strAsTyped[z]];
>
>found = FindStrInStr(yourTxtP, strToSearch, (Word *)&fldPos);
And Chris Antos then said:
>huh? i don't do any kind of conversion and it works perfectly well for me.
>and sure enough, looking at the OS3.0 ROM source code, FindStrInStr
>effectively does the conversion for me. maybe this is something that's
>required on OS2.0 or earlier, but i don't think i ever had a problem with
>that on OS2.0 either.
>
>there is no strToSearch string in FindParams. do you mean strToFind? at
>least on OS3.0 and higher, it should be perfectly safe to use strAsTyped
>instead.
>
>however, i think if strToFind contains some bogus string, that indicates
>something's going wrong outside the control of your app (assuming you aren't
>building up a FindParams struct on your own -- are you?).
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.
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.
This behavior hasn't changed since the initial release of Palm OS.
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.
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.
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.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200 (direct) +1 408-261-7550 (main)
