> you are confusing the Palm OS SDK with the palmOne SDK.

I don't think so. I have a Tungsten E device myself and some time ago was 
struggling with exactly the same problem - how to support the 5-way control. I 
was using the PalmOS 5.1 SDK that came with PODS checking for the Rocker 
characters didn't work. Then somebody told me to get an old SDK and use the 
nav* keys. I found from somewhere an archive that contained only the *.h files 
(i.e., no libraries, no tools) for the 4.1 SDK, unpacked them in a separate 
directory, told PODS to tell the compiler to search that directory for include 
files too and started checking for the nav* keys - and everything worked just 
fine.

Now, it could be that it was an SDK from PalmOne - but I don't think so. Not 
100% certain, though; I just no longer remember where I got it from. Boy, the 
split of Palm into two companies certainly didn't do any good and is just 
serving to incease the red tape and to confuse everyone... :-(

> but it detects the new Palm OS SDK and disables those parts.

How can one SDK "disable" another?! They are not programs; they are just a 
bunch of mostly include files. Do you mean that some of these files should 
overwrite others with the same name in the other SDK? In my case I keep them in 
to different subdirectory trees.

> With these two SDKs, you should have all the 5-way key defs
> needed for all palmOne devices.

How can I support, say, both the 5-way control of the Treos and that of the 
Tungsten E in a universal way? The glue APIs contains the necessary functions 
to support the 5-way control on all Treo-like devices (which includes several 
Tungsten models) - but not the Tungsten E. For the latter, I have to listen to 
keyDown events and to use the NavDirectionPressed/NavSelectPressed macros which 
I got from the 4.1 SDK. Is there a better way?

Regards,
Vesselin
-- 
For information on using the Palm Developer Forums, or to unsubscribe, please 
see http://www.palmos.com/dev/support/forums/

Reply via email to