Paul said:
>While feeding my program a few gremlins to chew on, it died this evening. I
>managed to track it down to the following. Calls to StrChr(str, chr) where
>chr>=256 causes a "StringMgr.c, Line:670, bad chr passed" error. The
>questions is, are these character valid? Gremlins seems to be typing them
>into some of my textfield that I'm filtering. I got around it by testing
>for chr>255 before the StrChr(str, chr) call.
>
>Is this supposed to be this way?
Keith said:
> When Gremlins posts a character >= 256, it also sets the commandKeyMask
> modifier. This allows SysHandleEvent to handle those characters. Hence,
> those characters should not be showing up in your text fields. Are you
> finding instances where that modifier is not set?
Paul said:
>Checking for the commandKeyMask set did the trick. Thanks.
>
><doc update>
>StrChr() will complain when told to search for characters > 255
></doc update>
1. Gremlins does indeed set the commandKeyMask bit in the keyDown event
modifiers field for characters > 255, BUT ONLY if they're really virtual
characters. It does not do this for double-byte (e.g. Shift-JIS Japanese)
characters.
2. Similarly, StrChr() complains when it is passed invalid character codes,
but the definition of what's invalid depends on the character encoding
supported by that particular rom. Thus if you pass 0x8140 to StrChr when
running on a rom that uses Shift-JIS, everything works just fine.
3. One problem to watch out for w/StrChr is sign extension of single-byte
characters which are > 127 (have their high bit set). The compiler will
attempt to sign-extend any single byte signed value (e.g. Char) when
pushing it on the stack as the chr parameter for StrChr. This means that
StrChr sees the passed parameter as being 0xFF80 (for example), which is
invalid.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 650-947-9222 (direct) +1 408-261-7550 (main)
