Menu2 addItem does not cause refresh of menu on Edge520Plus

There are lots of threads where there are attempts to change the menu while it's active, and non work.  About all you can do is change the label and sublabel.

Menu2 is a native view.

I've done my own lists outside of menus.  Here's one case where the list is a fixed size and fits on a single screen. up/down moves the highlight, and select expands the data for the highlighted item:

in another case, maybe similar to what you're doing, I provide a list of BLE scan results, one per page, and select switches between a summary and raw data:

Another thing you can do is not try to add to the menu, but just not have it open all the time, and only open it when the user requests it by way of something like onMenu()

That def sounds like a bug and you should push for it to be fixed. (Report a bug in the appropriate forum section)

You could also try using Dynamic Menu, which accomplishes the same thing, and gives a close to "native" experience, at least for watches in the 935 / Fenix 5 / 645 generation and earlier. The advantage here is that it also works with older devices (which are stuck on CIQ 2 and don't have Menu2).

https://github.com/flowstatedev/Dmenu

Disadvantages:

- Not the greatest code to work with

- Will never be as good as native implementation

- Consumes memory in code and data (there are ways to refactor the code to minimize this tho)

Yeah, like I said it sounds like a bug. The OP already said that it works on the sim and not on device, so I assumed that was clear to everyone.

jim_m_58 said:

Menu2 on devices is a native view, where in the sim it's being simulated.

Right. I think by definition, everything on the sim is simulated. Similarly, we can probably assume that most things in the CIQ API are wrappers around some native code. I do take your implied point that the sim isn't simply *emulating* the real device as one might incorrectly assume.

I don't understand the intent of this comment:

There are lots of threads where there are attempts to change the menu while it's active, and non work.  About all you can do is change the label and sublabel.

If Menu2 API is supposed to work a certain way (with the ability to add and remove items dynamically), then it's a bug if it doesn't work as designed. Whether it's a native view or not seems irrelevant.

jim_m_58 said:

The look and feel of a Menu2 is device-specific.

I don't see the relevance to OP's complaint that the *functionality* of Menu2 does not appear to work properly.

It means it might not work the same way in the sim as it does on a real device.

Which doesn't change the fact that if "addItem" doesn't work as specified in the *documentation*, then it's a bug. I think we've established that it doesn't seem to work properly and that it appears to be a bug.

So that brings us back to the suggestions in this thread:

1) write your own view

2) use DynamicMenu

3) file a bug with Garmin

Personally I would do 3) regardless. If OP can't wait for the bug to be fixed, it's up to them whether they want to do 1) or 2).

EDIT: there's also the suggestion of changing how the Menu is used (i.e. when to create/show it), which could change the UX/functionality of the app, depending on how it's supposed to work.

This also brings up an interesting point which has been raised repeatedly: it's frustrating to devs when the behavior of the sim is radically different than the on-device behavior. Most of us can't afford to buy every single device to test our apps, so we have to rely on the simulator to be somewhat similar to reality.

There are many things different in the sim that on real devices.  It was much easier when there were only 4 CIQ devices, but even back in those days it was said  "Remember it's a simulator and not an emulator"

I agree with FlowState.  Its very fustrating to develop based on what you read in documentation and test on sim, to then find it doesn't work on device.  Understood it is a simulator not an emulator, but this sort of thing seems quite basic, and would save a lot of people a lot of time.  With something where it gets populated through ANT messages over time, it can take a long time to debug.  Documentation would be a quick fix at least.

Either way though, I ended up rolling my own which is relatively light on code, and gives me all the functionality I need, so problem solved.