Menu2 question

and just to double confirm, are you passing :theme=>null in your options? If you are, and you still see some auto formatting taking place, I would submit a bug report. That doesn’t seem like expected behavior to me. 

You may want to use the menu2sample in the SDK to check things in the sim vs real devices, as what you see in the sim is a bit generic vs real devices and I've seen this in the past

In the API doc,

Note:

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

Back to the original 4 CIQ devices and Menu, the sim isn't always the same as real devices, and now with 100+ device I still see differences on some with Menu2.

Already using the sample app. 

inonly have 2 real devices: fr630 (does not support menu2) and fr265 (looks a bit different in real than on sim, on both custommenu item is not aligned with blue selection bar if wrong height is chosen)

menu2sample app has the same issue on the fr265 (for the custom menu items. All the  other types look fine)

I just tester: this solution does not work. The draw method is called for all menuitems as soon as the menu opens, so unfortunately does not work

Ah sorry to hear it :/.

Are you sure you can't get the Custom Menu to work? I put something together last night based on the Menu2Sample example (I based it off of the custom image example) and if I understood your requirements, I think I might have gotten something that resembles what you're looking for. I haven't pushed it to my fr965 yet though.

In the Menu2Sample example, it looks like they create a class that extends a CustomMenuItem. There's an if block in the draw function of that class that checks whether the item isFocused() and you can display things differently whether the item is focused or not, which I think is what you were trying to achieve.

https://github.com/dumpemout/MyCustomMenu

I'm sharing my github repository, hopefully you can access it. I'm new to all this lol. Basically I created a dummy getDeviceStatus() function that returns a pseudo-random number between 0-100 and if it's less than 34, it displays a red heart, if it's less than 67 it displays a yellow heart, and a green heart if it's 67+. The "status value" Sublabel and the icon only get displayed if the item is in focus, and I believe it only makes a call to the function to get the status if the item is in focus as well. I don't know how this would behave in a real scenario if you have to make calls over a local wifi connection or something. I also don't know what happens if the user is mid swipe (in the simulator, it looks like the draw function gets called multiple times per second while a user is mid swipe? Could be a sim bug).

Note, I noticed the same behavior with the ugly boxes but I was able to turn that off by passing the :theme=>null into the options of the menu. I created a pseudo-theme manually which should expand to the dc of the focused item without hardcoding anything. At least that was the plan. 

Apologies in advance for any poor code... maybe someone could tidy it up a bit. And I hope this gets you closer to what you need. If not, then I hope Garmin can bridge the gap with their API... either way, it was a good exercise for me if I ever need to leverage Custom Menus versus Menu2's.

I think isFocused is too late for what he wants to do, because he wants to run code (download something if I remember correctly) to decide what will be displayed. Obviously isFocused means it's already visible, so it's too late

oh, so couldn’t he technically build the menu dynamically and move that logic upstream in the app lifecycle?

maybe I’m oversimplifying things, but I have a watch face that runs a getComplications() method to figure out all the available complication types on my device and then I dynamically build a Menu2 based on those types and longLabels. The menu allows me to swap out existing complications on my screen. I have an exclude array that will skip certain complications that I don’t care about, but are available on my device. Nothing is really hardcoded, except the ignore array, and it’s all built programmatically. I could probably add a step somewhere that removes/adds complications to my ignore array based on some logic (time of day, for example) and then re-initialize the menu. Couldn’t he do something similar to decide what’s visible on the menu in the first place, before the draw() function gets called? And then he can make the URL calls in the isFocused block as to not make too many URL calls at a time?

I think I might be out of my depths here unfortunately lol.

dumpemout said:

oh, so couldn’t he technically build the menu dynamically and move that logic upstream in the app lifecycle?

That is exactly what I do,  I build the menus manually, and can decide what I want on the very top.