Avoiding the 'Menu' when holding Menu button.

The code of my stopwatch is basically "if key == KEY_MENU then reset" [in onKey]. It works perfectly fine on the sim [also the Fenix 5 sim] and on a real VAHR, and it used to work on the Fenix 5 before the firmware update.

Since users are now saying that the stopwatch doesn't reset anymore, I'm assuming that the onKey event is not being triggered when the default menu is opened. If this is the case [and yet not considered a bug but expected behaviour], then a statement such as "key == KEY_MENU" in onKey doesn't make sense [i.e., it will never return true because onKey will never be triggered with "key == KEY_MENU"].

I think that running the Input sample of the SDK on a real Fenix 5 will give the answer.

This was my happy and working InputDelegate before the change.

class InputDelegate extends Ui.BehaviorDelegate {
function onKey[evt]{
var key = evt.getKey[];
if[ key == KEY_ENTER]
{
if [mStopwatch_IsRunning]
{
mStopwatch_pause[];
}
else
{
mStopwatch_resume[];
}
return true;
}
else if[key == KEY_MENU]
{
mStopwatch_reset[];
return true;
}

return false;
}
}

r.485 - I downloaded your widget to the f5, and it does seem when when you push menu and get the new menu, selecting your app doesn't reset the time.

I know this works for me in my apps and widgets, but instead of using key==Ui.KEY_MENU, I use onMenu. If you want to try that, you can pass on a sideload and I'll give it a try.

Thank for testing, Jim!

I think/hope it will work with onMenu, but I'm considering other solutions too [now that I know how to handle other buttons in a widget context. Thanks for that too, again! ;-D].

My point now is just that "onKey" is not triggered. If this isn't considered a bug, then the Input sample of the SDK is wrong/misleading, since its onKey includes a "if [key == KEY_MENU]" that will never occur.

If you have time, could you please check how the sample does in your F5 to confirm this? I guess the "action string" won't be set when the menu key is pressed, as meant in the code and as it does in the sim.

In my point of view, a solution would be to let onKey happen before the default menu appears [not sure if the guys at Garmin will like to change the firmware for that...]

And just as a remark, I believe that I chose "if [key == KEY_MENU] then doMyStuff[]" because it was cheaper in memory than "function onMenu[] -> doMyStuff[]". [since my input delegate already implemented onKey for handling other keys].

--
Now some more criticism about this change:

This change is pushing me to open my menus with the start/stop button. It saves a lot of time for the user because
1. he doesn't have to press and hold a button, but just press
2. he doesn't have to navigate an extra menu
3. my approach won't cause confusion by mixing my app's functionalities with the native stuff
So, if the intention was to make CIQ widgets and apps more consistent with native ones, it has actually become a reason for me to deviate more from them.

Hey r.485,

I the fenix 5 devices, Chronos, and 935 have all implemented this change. The goal is consistency with the way that native apps behave. I tested this issue on a fenix 5X here with the input sample in the SDK. This returns both onMenu() and KEY_MENU as you have implemented it. I am receiving both on the current firmware so I don't think there is a firmware bug, however I do understand your point about differentiating between native and CIQ items.

Update: I tried your widget and I too am not able to reset it. There is definitely something not working correctly. Would you be willing to send your source to [email][email protected][/email] so we could try and dig a little deeper?

Thank you,
-Coleman

Hi Coleman,

I just sent the project by email. Thanks for having a look at this issue.

By the way, I updated the app yesterday and now I'm using onMenu[]. Could a Fenix 5 owner let me know if it works now ? [i.e. if the time resets if you choose the menu option]

https://apps.garmin.com/en-US/apps/330c059e-b534-4594-9372-064f5d04681f

Thank you!

I have a couple of widgets which uses KEY_MENU which work fine with 5.30 firmware, albeit now having to press select after the menu key before the widget gets the KEY_MENU event.

I can understand why this is done, but it really messes with my widget flow. I use the up and down buttons to move through my data one item at a time. I use a long press of these i.e. KEY_MENU and KEY_CLOCK to move through my data one page at a time. This no longer really works given the KEY_MENU is not generated unless you long press the menu button and then press the select button.

If the watch had always worked like this I probably would not have designed the widget like this. I'll probably re-code so I can detect a double press and use this to page through the data instead of using a long press.

I also expect I'll get feedback from another widget that the menu key no longer works and I'll have to explain to users they now need to press select afterwards for the menu function to work.

Just downloaded from the store r.485, and it still doesn't reset. But now that Coleman has the code, I'm sure something will be found here.

I have a guess!

I never used

function initialize[] {
BehaviorDelegate.initialize[];
}

Now I see that the compiler gives a warning about it, but I probably never bothered because all my apps worked without it.

If we confirm that this is the reason, maybe the next version of the SDK should give an error instead of a warning?

Just uploaded a new version of the stopwatch (2.3a) using initialize[]. Would you mind to test it again, Jim? Thanks!

That was a good guess r.485, but it's still the same.. No reset.