> >Why does TxtGlueCharIsPrint( vchrNavChange ) == true when it should be>false?> printing character will ever have that set, AFAIK.
I think you need to filter your processing to throw out any keys with the command flag set before you try to process them as printable or not. No
Ben, as usual, is correct.
I did implement a workaround, but the point of my post was to point this out as a bug in the TxtGlueCharIsPrint/TxtGlueCharIsGraph functions. These functions have no trouble returning false for other virtual keys such as vchrClock & vchrPopupBrightness, and only seem to be problematic on the vchrNavChange key.
TxtGlueCharIsPrint is a macro that calls TxtGlueCharAttr(). On a Tungsten|T or Z71, the TxtGlueCharAttr function will call TxtCharAttr68K in PACE, which will in turn call the real ARM-native TxtCharAttr function.
On debug ROMs, if you pass virtual characters to TxtCharAttr, you'll get a non-fatal alert. On release ROMs, it will blindly use the character code value as an index into an array of attributes. Since this array only contains 256 elements, a virtual character winds up returning random data. That's why it just happened to work with vchrClock & vchrPopupBrightness, but not vchrNavChange.
I could do:
if ( ( pEvent->eType == keyDownEvent ) && ( !TxtGlueCharIsVirtual( pEvent->data.keyDown.modifiers, pEvent->data.keyDown.chr ) ) { if ( TxtGlueCharIsPrint( pEvent->data.keyDown.chr ) ) { do my thing } // else let system have it }
but I shouldn't have to use this extra function if TxtGlueCharIsPrint worked properly...
There are two issues.
1. Eventually you'll be dealing with Unicode code points. These overlap the virtual character code range, thus the only way to distinguish them is by whether the command bit is set in the event record.
2. For performance reasons, TxtCharAttr doesn't do character validation on release ROMs. If this wasn't the case, then we could return back something benign when you pass in an invalid character code - though as per point #1, eventually this wouldn't save you.
[BTW, the command modifier bit was not set for virtual keys until OS3.1, according to the Palm OS Reference, but TxtGlueCharIsVirtual handles this for OS3.0 as well.]
Actually it was set for virtual keys prior to 3.1. The note should say that it wasn't set for _all_ virtual keys. I think the previous or next field virtual keydown event didn't have its command bit set when generated by Graffiti, but this was fixed in 3.1.
-- 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/support/forums/
