Action Menu does not work with touch/mouse in the simulator - app crash

With the newest devices (venu4, venux1, vivoactive6) neither the keyboard (up/down/enter) - which is understandable - nor clicking on the watch's enter button work in SDK 8.3.0. 8.4.0. So these devices are impossible to test in the simulator.

This is exactly what I described in my original post, other than I did not try the keyboard. 

I added ActionMenu proper. And in the simulator (8.4.0) with fr955 I have a different experience:

The ActionMenu is displayed as a response of a user action.

- if I click the start button of the simulated watch with the mouse, then the ActionMenu closes itself and everything is as expected

- if I hit enter on the keyboard, then the ActionMenu closes itself and works as expected

- if I click on the line of the action menu with the mouse (simulating a touch), then the action works (i.e: onSelect is called with the correct item) BUT the ActionMenu is not closing itself. It is still on the display. Next thing (almost anything I do) causes a crash.

For the first 2 cases (click the watch button or hit enter) it works no matter how many times I do it (of course it means that the ActionMenu is closed, and a new one is showed after the user does trigger it again)

I'm not sure I understand your issue. I just added recently action menu for an app of mine

...

OK, now I know what's happening in my case.

and there I use Menu or Menu2.

...

what is the reason one would use ActionMenu? Looking at the functionality, it's better to use Menu2 ... So what am I missing here?

So...the op literally says "action menu" both in the title and the body, *you* literally said you added an action menu, and - huge surprise - it turns out that you weren't using an action menu after all. As a matter of fact, you don't think that anybody should be using ActionMenu at all (which is highly ironic in light of your earlier statement "I just added recently action menu"). (I realize that you apparently didn't think an "action menu" is the same thing as the ActionMenu class, and/or that perhaps you thought an "action menu" is any kind of menu that you push in response to the action menu indicator being activated.)

This is why careful reading and writing is important. By double-checking the things that you read and especially the things that you write, you can spot mistakes in your thinking and actions right off the bat. Ofc most of the non-technical users in this forum (and everywhere else on the internet) write very sloppily, which also reflects sloppy thinking, but I'd expect more from technical-minded people.

Also, instead of immediately assuming that OP has no idea what they're talking about [*], you could give them the benefit of the doubt and put 30 seconds more effort into trying to understand and recreate their problem since you're willing to implicitly critique it / ask questions.

(* i.e. "I'm not sure I understand your issue" really means "I don't know what you're talking about" which really means "I think you don't know what you're talking about")

Tbh when you originally commented "I'm not sure I understand your issue" I wanted to say something, but I held my tongue. Like what is there to not understand? OP explained very clearly what they are doing and what they see. Any failure to understand the problem is clearly not OP's fault.

It would be different if you actually tried to recreate the problem properly, and didn't see the same behaviour, but ofc that is not what happened.

For example, once you saw that you were not able to recreate OP's problem, you could've taken 5 seconds to search up "connect iq action menu" - the ActionMenu class is literally the first result, and if you had tried to use that class, you would've seen the same problem as OP.

what is the reason one would use ActionMenu?

1) Because it's the *Garmin-recommended* UI view to push when the user activates the action menu indicator on the new touch-first watches which don't have a menu button shortcut.

It's literally in the name - action menu indicator - and the docs explicitly state that you're supposed to push an action menu when the user activates it.

(Yes I'm aware that even Garmin sometimes pushes a regular menu when the user activates the action menu indicator).

2) for the same reason that Garmin themselves use action menus. An action menu is a less obtrusive form of context-sensitive menu (it only covers half the screen) compared to the classic full-screen menu which completely takes you out of the context of what you're currently doing. That's why a lot of the native glances use action menus for various context-sensitive menus in watches like FR955 (and newer models).

gasteropod said it better than me.

I'll turn it around and say why *shouldn't* one use ActionMenu?

Garmin added it to their devices for a reason. They tell us to use it for a reason.

3) "Looking at the functionality, it's better to use Menu2"

Even if this were true, functionality is only 1 piece of the puzzle. There is also such a thing as UX. (Something that Garmin is terrible at, but at least they've tried to improve over the years).

Even if Menu2 actually was better than ActionMenu in all ways, it's not a good answer to the problem of "action menu does not work..." to say "use Menu2 instead", especially when ActionMenu is newer than Menu2, and Garmin literally recommends using ActionMenu in some cases. It's not like we're talking about Menu (for example) which is known to have a bug which will never be fixed, and which is basically only "necessary" for devices which are 9-10 years old, having been superseded by Menu2 (which as you pointed out, is supported on a wide range of devices).

Clearly there is a bug, and the exact symptoms seen vary slightly dependent on how it is invoked.

Yeah to be fair I was very lazy and I didn't bother to push the action menu in a "realistic" way (i.e. in the response to user input or some other app event).

I'm sure that if I did it properly (your way), I'd see the same thing.

Either way it's a bug, and even if Menu/Menu2 was always the superior choice (even though that's not true at all), it would still be a bug.

Now I have got up and had time to look at your code, I can get the same behaviour as you if I move my action menu to be pushed from onShow().

If an action menu is pushed from onShow(), it does not get popped automatically irrespective of using touch or buttons, and crashes if the back or enter button is pressed after an initial selection which I can see does call the delegate.

If an action menu is pushed from an input or behaviour delegate, it appears to work fine if you just use buttons, but if you attempt selection using touch, it does not get popped automatically, and crashes if the back or enter button is subsequently pressed

Clearly there is a bug, and the exact symptoms seen vary slightly dependent on how it is invoked.