SIM_BUG? -- KEY_START vs KEY_ENTER

In the API documentation, http://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/WatchUi.html
There are 2 keys listed

KEY_ENTER = 4 The enter key Since: 1.0.0
KEY_START = 18 The start key Since: 1.1.2

I have been using KEY_ENTER and it works for the 920/VA/F3

then comes the FR630. I had an app ported over to the FR630 and somehow, it is not recognising KEY_ENTER but instead it is using KEY_START (this is for the Right hand side top button)

In the Simulator, the key mapping will come up as KEY_ENTER but on the actual hardware, it comes out as KEY_START
this caused me undue mental anguish in trying to figure out what was happening to the app and why it is not working as expected.

Can I please get some clarity between the KEY_START and KEY_ENTER?
What is the difference and which should be used to START activity recording?

OR.. is the same KEY (Right Top button) being used for 2 different purposes based on context?

eg:
to start an activity, it will be mapped to KEY_START
but when in a MENU, it will be mapped to KEY_ENTER?

how does it work?

Obviously the note in the FR230/235/630 about 1.1.4 apps working on FR630 is not entirely true

Everything built on either 1.1.4 or 1.2.0 will work absolutely perfectly

:-p

Former Member over 9 years ago

I think there is a change that will be coming through for this in a update for the 630. Technically the key on the 630 is not used as an enter key on the product, but to stay consistent with other products, I think they are planning to fix it to match the simulator and send the Enter key event.

Nikeow over 9 years ago

staying consistent is good. Appreciate it. But as of now, apps will need to be changed to recognize the new key then.

One other thing, I sent an email to you regarding some weird behaviour in an app I'm porting to the new devices. Can u take a look at it based on an actual HW? It's exiting prematurely directly after pressing enter/start.

Former Member over 9 years ago

Did you send the email to the ConnectIQ mailbox? I don't see it in there. I've seen some discussion that leads me to believe there is a device bug that could be occurring on the new devices if you do not return true from the input delegate, so I would check that first.

Nikeow over 9 years ago

Oops... I didn't previously but I've just now fwd it to that mailbox. (it has a 7MB video file - so perhaps it's a tad big for the mailbox?)

Previously I was talking to Brandon and thus I just used back the same email thread.

Appreciate the feedback based on actual hardware.

Return True you say..
may I ask where should the "return true" be placed?

class myInputDelegate extends Ui.InputDelegate {
function onKey(evt) {
     if( evt.getKey() == Ui.KEY_ENTER ) {
     // do a bunch of things
return true;
     }

     if( evt.getKey() == Ui.KEY_ESC ) {     
     // do a bunch of things
     }

     if    ( evt.getKey() == KEY_CLOCK) {
     return true;
     }

function onSwipe(evt) {
   var event = evt.getDirection();
   if         (event == Ui.SWIPE_LEFT) {
   // do bunch of things
   }

return true;
}

Which "return true" would you be referring to? the one in BLUE or the one in RED?

Nikeow over 9 years ago

also want to confirm on the key mappings.
seems like the FR630 has entirely new key mappings?

the right hand side lower side button is now the LAP button and the left side lower side button is the BACK/ESC button?

are these going to be changed to be consitent w/ the other products or it will be unique for the FR630(?). I think the FR230/235 is similar to the F3 correct?

Thanks for clarification

Former Member over 9 years ago

The return statement in blue would be the one in question. You may be able to prevent the device from triggering native behavior by indicating that you processed the key, but it depends on what exactly is causing the bug. You obviously can't do this if you push a native view that doesn't have a standard input delegate, so that is probably still an issue.

Yes, the 630 has a bit of a different paradigm with regard to buttons. It matches the design of its predecessors, but is unique among ConnectIQ devices. The 630 does have a LAP button, which unlike all other ConnectIQ devices, does not share functionality with the ESC button. This is essentially the same as the issue you encountered with the START key, but I'm not sure we can just patch over the inconsistency the way we are planning to with that one. It doesn't seem like we can just change the LAP key to the ESC key since there is already a different ESC key on the device.