At 12:00am -0700 00-06-29, Palm Developer Forum digest wrote:
>Subject: chrShortcutStroke and Latin-1 character set
>From: "Joseph Koral" <[EMAIL PROTECTED]>
>Date: Wed, 28 Jun 2000 09:42:42 -0400
>X-Message-Number: 16
>
>Why does the shortcut character (chrShortcutStroke) persist in a text field
>if no text is entered after it?
A current limitation in the way that shortcuts are implemented,
mostly involving the field code. Typically the shortcut character
gets removed when the user completes the entry of the shortcut, but
if they tap off the field, or quit the form/app before completing the
shortcut, then the shortcut character will get left behind.
>In my application, if a user enters a shortcut character in a text field,
>chrShortcutStroke is mapped to chrEndOfTransmissionBlock in Chars.h, which
>is 0x17. My conduit gets 0x17 and it's XML parser chokes because it is not
>in the iso-8859-1 character set.
>
>For the short term, I'm just stripping out chrShortcutChar, but what would
>be a more general solution?
Before saving a field, you could call the TxtStrEncoding routine. If
it returns the same result as the device's character encoding, then
you know that the string contains "special" characters. Unfortunately
this will only work in newer versions of the OS (i.e. _after_ 3.5),
since all current versions of TxtStrEncoding will return
charEncodingAscii for anything in the 0x00..0x7F range.
Hmm, on the other hand you probably also want to catch _any_
character in the control range (other than tab or linefeed or null),
even if it's not a specific Palm extension to the Windows 1252 code
page.
So if I had to solve this problem, I'd write a simple routine that
loops over the text in a field when the field is about to be saved,
looking for bytes in the range of 0x00..0x1F (but not tab or
linefeed). You know that none of these values will ever be part of a
multi-byte character, so it's safe to walk the string a byte at a
time.
>I see there are other "special characters" in
>Chars.h:
>
>// Special meanings given to characters by the PalmOS
>#define chrOtaSecure chrDeviceControlFour // 0x0014
>#define chrOta chrNegativeAcknowledge // 0x0015
>#define chrCommandStroke chrSynchronousIdle // 0x0016
>#define chrShortcutStroke chrEndOfTransmissionBlock // 0x0017
>#define chrEllipsis chrCancel // 0x0018
>#define chrNumericSpace chrEndOfMedium // 0x0019
>#define chrLeftArrow chrFileSeparator // 0x001C
>#define chrRightArrow chrGroupSeparator // 0x001D
>#define chrUpArrow chrRecordSeparator // 0x001E
>#define chrDownArrow chrUnitSeparator // 0x001F
>
>Can any of these other characters be input into text fields by the user?
The left/right arrows can be entered via Graffiti, but the field code
just uses them to move the insertion point. Only the shortcut
character gets entered into the text data.
>How can I force my app to only work with the Latin character set? Ideally,
>if run on a Palm with a different encoding, it would pop up an error message
>(future versions may support other encodings).
You can determine the device's character encoding by calling
FtrGet(sysFtrCreator, sysFtrNumEncoding, &encoding). If the encoding
is anything other than charEncodingPalmLatin, you're not running on a
device that uses the Latin character encoding. Note that if the call
to FtrGet returns an error, you can assume that the device's encoding
is Latin.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
