Mitch Fawcett said:
>Below are the events that that occur right before gremlin gives me a "wrote
>to low memory" error.
>
>39.126 (725): <- EvtGetEvent: penUpEvent X:137 Y:78
>39.126 (726): -> EvtEnqueueKey: ascii = 0x008D, keycode = 0x0000,
>modifiers = 0x0000.
>39.126 (726): <- EvtGetSysEvent: keyDownEvent Key:0x8D, Modifiers:
>0x0000
>39.126 (726): <- EvtGetEvent: keyDownEvent Key:0x8D, Modifiers:
>0x0000
>39.126 (726): -> EvtAddUniqueEventToQueue: fldChanged ID: 1102
>39.146 (726): <- EvtGetEvent: fldChanged ID: 1102
>
>I don't understand what the 0x8D key represents? I thought visible
>characters that a user might enter into a field in real life would not
>exceed 0x7F.
and Keith said:
>Whip out the Palm Computing Hardware Platform Connected Organizer of your
>choice, bring up the Graffiti Help system, and scroll on down to the 5th
>screen. There, you'll see characters (such as the Yen and Beta symbols)
>that are not defined as being in the standard ASCII code range (0x00 -
>0x7F). Rather, they are defined in the Extended character code range of
>0x80 - 0xFF.
>
>Off the top of my head, I don't know what glyph 0x8D corresponds to. But
>Gremlins is free to poke character codes up to 0xFF at your application.
1. Keith is correct in noting that 0x8D is in the extended ascii range, for
the Latin character encoding, and thus can be returned by Gremlins.
2. As a side note, 0x8D is a bit of an odd case. It was the diamondChr
character in 1.0 through 3.0 fonts, but is now undefined for rom versions
3.1 & 3.2. If and when Microsoft extends its code page 1252 to use this
slot, the Palm OS fonts will probably be updated to match.
3. Note, however, that Gremlins can return any valid character code (even
undefined glyphs) in the keydown event. This means that on a Japanese
device, you could get something like 0x8140 (a double-byte space), or
0xE040 (the first level-2 Kanji). Heck, in the future you might even be
getting Unicode character codes, which cover the entire range from 0x0000
to 0xFFFF (less a few reserved/invalid code points).
What this means is that you should use the WChar type (a 16-bit value added
to the 3.1 headers) for variables & routine parameters which are for
characters as opposed to bytes. One of the common mods that had to be made
to the built-in apps was changing Char routine parameters to WChar, as
otherwise the high 8 bits from the event records .chr field were lost.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200 (direct) +1 408-261-7550 (main)
