You're testing for the wrong thing. The navFtrVersion returns the version
of five-way navigation support that's in the system. This is the
combination of fnav resource support and FrmNav APIs that was introduced
on the Treo 600. The use of vchrRocker codes is orthogonal to that;
TapWave Zodiac devices use those codes, but they don't support the
five-way navigation APIs.
However, you really don't need to detect the device type just to pick what
set of nav key codes to use. Just accept all three or four different sets
of codes -- the main ones are the palmOne five-way keys used on older
PDAs, the PalmSource standard vchrRocker keys, and the scroll wheel codes
from the Sony and early Treo devices. If you just write a translator
routine that turns any instances of the older key codes into the standard
vchrRocker codes and then have your main code just deal with vchrRocker,
you'll be in good shape.
Thanks Ben. That solves most of my problem. The only remaining issue is on
the navigatorless devices, like the much older Palms, the low-end Zires,
etc., I map some of the navigator functions to the hardkeys. So, if
hardkey1 gets pressed, its function is dependant on whether or not a
navigator is present. So, even if the navigator isn't used, I need to
detect if it's there -- how would you recommend I do this for the Tapwave?
Should I just test the device type for this special case?
Thanks,
Rich
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
