Load MenuItems dynamically

[skytracer]

The menu items (and/or menus) can be added dynamically?
For example, I have a list of log dates that I need to be added as menu items when a "Show logs" menu is selected.
I am not sure whether this has a memory impact when you go back to the main menu etc

Thanks

[jonblack]

I don't see why not. As long as you hold on to the Menu* that represents your "Show logs" menu, you should be able to dynamically add MenuItem* at runtime. Eventually you will run out of memory on the heap but I doubt it's much to worry about.

Have you tried adding menu's dynamically? I think this would be a nice example.

[skytracer]

Running out of heap could be an issue, although I don't know what are the case for that.
For example, how can I scroll though a list of logs?
Having, let's say, 50 logs, read sequentially from an external EEPROM, with 5 logs per page, how these 5 MenuItems can be recreated on next page? Making 50 MenuItems and scrolling through won't work

Thanks

[jonblack]

Since you're showing 5 per page, you could hold on to the five MenuItem's and re-use them every time the page changes . Granted, it's a bit tedious, but I can't think of another way off the top of my head. I'm planning to look all the pull requests and issues this weekend, so I'll try this out and see if I can think of a better way.

[gzabusek]

Hello there, i am in need of the same functionality. In theory dynamic menus can be created no problem. But the issue is that there is 'remove_item' missing to remove the dynamic item later (and therefore prevent memory leaks). I could implement this today, please let me know if you would like me to do it.

[jonblack]

Issue #31 will be needed to support dynamic menus. Adding an optional callback when the Menu is selected povides a trigger for loading dynamic menu items.

Another option is to subclass Menu with DynamicMenu specifically for this purpose.

[eadf]

Now that #22 (NumericMenuItem) is in the code the 'show log' use case can be solved with a subclass of NumericMenuItem.

The value of the menu item can be used as the log index. And the get_composite_name() returns a sub-section/view of the log (this can be a multi row value).

While the user is 'editing' the NumericMenuItem he is actually scrolling through the log. Care has to be taken so that the _maxValue and _minValue matches the actual log size.

This can be done without dynamically adding any menuitems to the menusystem.

[gzabusek]

Hello there, I believe adding the DynamicMenu would be a nice and clean solution. Let me know if i should do it. I would be more than happy to contribute :)

[jonblack]

@eadf That's one option. There would still need to be a way to trigger loading those items (#31).
@gzabusek I'm going to look at this today and see what I come up with.

[eadf]

Hm, I don't think there will be any need for a trigger. To display a log we would only need one single MenuItem, a subclass of NumericMenuItem. Normally it will just display the name of the log, while in edit mode it will scroll through the log rows.

[jonblack]

@eadf Some users might want a single MenuItem per log file. Also, users might want to do something when a dynamic menu item is selected. Adding an on_select callback to a Menu gives the client a lot of flexibility over how a dynamic menu it created. They can still create their own NumericMenuItem subclass if they want, but it shouldn't be part of the library. I want to avoid deep class hierarchies. We might need to do something about MenuItem::on_select so the callback has more information to work with.

[eadf]

Some users might want a single MenuItem per log file

Yes, that's what I ment. Maybe i should have typed it like this..
"To display one log we would only need one single MenuItem"

They can still create their own NumericMenuItem subclass if they want, but it shouldn't be part of the library

That is also what I envisioned, it would be impossible for us to know anything about how the end user reads the log. My point is simply that the use case "display logs" can be solved without adding dynamic menus to the library.

LogMenuItems can be added by an example, reading static data for simplicity.

[jonblack]

In your example when does the NumericMenuItem subclass get created?

[eadf]

It's allocated just like any other MenuComponent. In setup() or globally (like in serial_nav.ino).
When the NumericMenuItem subclass enters 'edit mode' it will have to query the actual log to fetch the valid _maxValue.

[jonblack]

I think I understand now. I still see limitations. The number of log files could change at run time (e.g. rotating every 24 hours/every 100kb), but the menu items that represent them are only created once during setup.

In any case, it's still a novel approach and worth an example. For some people this might be enough. I still think we need the other approach though. Do you agree?