Avoiding the 'Menu' when holding Menu button.

Hey,

I was able to reproduce this and have a ticket started with the product team.

Thanks,
-Coleman

See here:

https://forums.garmin.com/forum/developers/connect-iq/1242292-onmenu-not-working-in-app-any-more?p=1242321#post1242321

it seems this is expected behavior.

I need some clarification on this issue.

- Is [was] there a problem or a change with how the menu button of the Fenix 5/5X was handled in widgets?

My specific issue: I have a simple stopwatch widget in the store: https://apps.garmin.com/en-US/apps/330c059e-b534-4594-9372-064f5d04681f

In order to reset the time, the user must press the menu button [hold UP on the Fenix 5X]. I didn't want any menu to be shown, just reset. And this is working fine on all other devices.
At the same time that this thread was started, I received reports from Fenix 5X users saying that they weren't able to reset.

Now, based on the information in this thread and in the related one, I couldn't conclude if it was a bug which would be fixed or if there's a permanent change in the way the menu key will be handled. In the other thread, Brian.ConnectIQ posted "This change was made to allow access to the general device menus while Connect IQ applications are running". If it is going to be this way, then I'll have to change my approach to reset the time.

IMHO, what Brian says isn't a good idea, especially for widgets. I think that there are already very few ways to interact with it. So letting us handle the menu key would give us a bit more freedom. And widgets have a short life, so the user can just close it and open the device settings from the watch face. If Brian meant only watch-apps, I'd understand the point, but, still, the developer guide says "While running, the app has full control of the UI". https://developer.garmin.com/connect-iq/programmers-guide/

Kind regards

As you can see in the other post I have also mentioned that this change is not a good idea in my opinion, as it changes the behavior of a lot of apps/widgets and the "menu"-button is not of use any more. But it seems that this behavior is expected and was added with CIQ 2.3.2. I also use this button in a stopwatch widget and it does not work any more without the "undesired" menu. According to Brian this will also not be changed back.

From Brian's post, this sounds like a move to make CIQ widgets/watch-apps consistent with native widgets and watch-apps, giving them the ability to access the system menu. It's not a CIQ 2.3.2 thing, it's something done by the platform/firmware groups.

While today it's just the f5 family and 935, I'm guessing it will start to be seen on other devices in upcoming FW updates.

Things still work with the extra menu, but there's an extra step. When you press "menu", you get this menu, but the first item is your app, and if that is selected, your app's onMenu runs like it did before.

I'm looking at my apps and widgets to see if I want to change some things to reduce the use of the menu button, as well as a second thing that might come up. - In the past, when you started a CIQ app, things like system settings couldn't change while the app was running, but now they can change. So if an app starts with distanceUnits set as statute, they might change to metric while the app is running, for example, and I'm making sure that won't cause any problems. It's been this way for DF's all along so there's no impact to them.

The problem is that in various apps/widgets there is no alternative as those need this button to add custom logic. Also there was no warning about that, it simply changed...

Maybe they could add a long press to the "select"-button instead, this would be a good replacement.

Bye

As I said, the menu button still works, it's just when you get the menu, you have to select the first item for onMenu in your app to run.

Ok, if necessary we'll adapt our apps. It would be good if we could be informed about such a relevant change in advance.

Anyway, I think there's another issue related to this. In my stopwatch, I actually don't use onMenu or the other 'behaviour' methods, but I use the onKey event to check which key was pressed [if key == KEY_MENU ...]

It seems that onKey is ignored when that default menu opens [maybe someone with a Fenix 5 can write a small program to test it?]. If this correct, then key == KEY_MENU in oKey will never make sense - and it's in the Input sample of the SDK.

On the watch or the sim - with KEY_MENU?

Be sure to check what you return for an onKey! In all cases return the true/false, and for keys you don't handle, aways false...