Probably it wouldn't hurt to filter out virtual keys, command keys, etc before calling the TxtXxx() APIs.
"Ken Krugler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > >I am trying to filter out "illegal" characters as the user is writing them > >into a text field. To do this I wait for a keyDownEvent and then I process > >it with the following code: > > > > case keyDownEvent: > > ch = pEvent->data.keyDown.chr; > > handled = ! ( TxtCharIsAlNum( ch ) || TxtCharIsCntrl( ch ) ); > > break; > > > >If handled = true > >Then > > the system does not concatenate the character to the field. > >Else > > the system concatenates the character to the field. > > > >When I look at the results of TxtCharIsAlNum() it works correctly on the > >Palm OS Emulator (Sony Clie). > > Which ROM? I'm assuming this is 4.x (since you mention POSE). > > >On the device Sony Clie NX60 (Palm OS 5.0) it > >returns 0 for all character values including international characters. > > > >Has anyone run into this problem? Or does anyone have any ideas on the > >cause of this defect and maybe a work around? > > The PIM apps and other 68K bits and pieces in the OS use the results > returned by TxtCharAttr(). So it would surprise me if this was > returning something invalid. Can you provide information on what > TxtCharAttr returns for 'a' and '0'? > > Also, one occasional problem is when the variable ch (in your example > above) is declared as a char or Char instead of a WChar. When you > pass this to TxtCharAttr, the compiler will sign-extend the value to > be 16 bits, and thus if the high bit is set (for high-ASCII) you can > wind up passing 0xFFxx instead of 0x00xx. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
