That's pretty close to what I came up with. Which is:
if( event->eType == keyDownEvent )
{
if( IsFiveWayNavEvent( event ) || event->data.keyDown.chr ==
vchrHardRockerCenter )
{
if( NavDirectionPressed( event, Up ) || event->data.keyDown.chr ==
vchrPageUp )
ScrollList( SCROLL_UP_SINGLE, true );
else if( NavDirectionPressed( event, Down ) || event->data.keyDown.chr ==
vchrPageDown )
ScrollList( SCROLL_DOWN_SINGLE, true );
else if( NavDirectionPressed( event, Right ) )
ScrollList( SCROLL_DOWN_PAGE, true );
else if( NavDirectionPressed( event, Left ) )
ScrollList( SCROLL_UP_PAGE, true );
else if( NavSelectPressed( event ) )
HandleSelect();
}
}
This works (and is what I'll use if I can't find a better way) but it makes
for wierd behavior which is why I wanted to try Ben's suggestion, setting
"Interaction Mode".
The Tungsten C produces 2 key down events for each button press.
NavKeyPressed doesn't work for the 1st event but does for the second one.
Same with NavSelectPressed. Almost the same thing with the T5 except I only
get 2 key down events with the select button. The extra event will cause
problems in some of my handlers beacause they need to handle other non-5-way
key down events. I'll write an ugly special case for them if I have to.
"Logan Shaw" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jim McGowen wrote:
>> Well after much toil I'm back where I started, only even more confused
>> than I was.
>>
>> What I want to do is handle 5-way navigation key down events. I don't
>> need "one-handed navigaion" or focus rings ect... I simply want to handle
>> scrolling and selecting in a custom list control I made. I got this
>> working over a year ago with the Tungsten C but the new navigation
>> features on newer devices boke it.
>>
>> What I've gathered from the documentation and from Ben is I need to put
>> my forms in "Interaction Mode". The docs tell me I can use
>> FrmSetNavState() to do this, but this function causes Sys 0505 errors
>> (and later on in the doc it actually say's don't use this with the T5).
>
> You don't actually need to do that. If you don't, the system will just
> send you regular pageUpChr and PageDownChr characters. You can just
> treat those as equivalent to 5-way up and down presses. At least for
> most purposes you can.
>
> I use code that looks like this:
>
>
> #include <palmOne_68K.h>
>
> .
> .
> .
>
> switch (eventPtr->eType)
> {
> case keyDownEvent:
> if (EvtKeydownIsVirtual (eventPtr))
> {
> if (NavKeyPressed (eventPtr, Up)
> || eventPtr->data.keyDown.chr == pageUpChr)
> {
> Handle5wayUp();
> return (true);
> }
> else if (NavKeyPressed (eventPtr, Down)
> || eventPtr->data.keyDown.chr == pageDownChr)
> {
> Handle5wayDown();
> return (true);
> }
> else if (NavKeyPressed (eventPtr, Left))
> {
> Handle5wayLeft();
> return (true);
> }
> else if (NavKeyPressed (eventPtr, Right))
> {
> Handle5wayRight();
> return (true);
> }
> else if (NavKeyPressed (eventPtr, Select))
> {
> Handle5waySelect();
> return (true);
> }
> }
>
> return (false);
> break;
> }
>
>
> Note that my "if" statements have extra conditions for up and down
> that they do not have for left and right. Also note that this means
> I don't distinguish between devices with and without 5-way. Devices
> without 5-way are basically treated as if they have a 5-way but the
> left, right, and center buttons are missing. I think there could be
> some cases that this isn't flexible enough to handle, but it works
> well enough for many purposes.
>
> - Logan
>
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
