RuntimeMenuItem don't seem to active onCommit or observer s

[emaayan]

so i'm to create a menu of countries and cities
where the countries menu get populate from a JsonDocument
and cities menu will also be populated from a JsonDocuemnt based on the selection of country
both selections will be stored on eeprom upon user simply clicking on the selected country and/or selected city

both countries and cities are using RuntimeMenuItems , and there are about 200 countries
and each city list can also reach upto 200 entries

while i'm aware i cannot call eeprom save on fn_invoke, i can't seem to find a method that would triggered once for a RunTimemenu selection.

neither onCommit or observer class methods are being used when i actually click on RuntimeMenuItem itself

void onCommit(int menuId)
{

    if (menuCountry.getId() == menuId)
    {
        const char *ctr = saveCountry();
        loadMenuCity(ctr);
    }
    if (menuCity.getId() == menuId)
    {
    }
}

class MyObserver : public MenuManagerObserver
{
public:
    void structureHasChanged() override
    {
    }

    bool menuEditStarting(MenuItem *item) override
    {
        const menuid_t menuId = item->getId();
        if (menuCity.getId() == menuId)
        {
            if (hasCountry())
            {
                const char *ctr = getCountry();
                loadMenuCity(ctr);
            }
        }
        return true; // allow editing to start
    }

    void menuEditEnded(MenuItem *item) override
    {
        const menuid_t menuId = item->getId();
        if (menuCountry.getId() == menuId)
        {
            const char *ctr = saveCountry();
            // loadMenuCity(ctr);
        }
        if (menuCity.getId() == menuId)
        {
        }
    }

    void activeItemHasChanged(MenuItem *newActive) override
    {
    }

} myObserver;

void initSystem()
{

    status status = loadCountries();
    if (status.code > 0)
    {

        u_int32_t initConf = loadInit();
        loadCountry();
        loadCity();
        setupMenu();

        const size_t totalCountries = countries.as<JsonArray>().size();
        menuCountry.setNumberOfRows(totalCountries);
        menuMgr.addChangeNotification(&myObserver);
        //  menuMgr.setItemCommittedHook(&onCommit);
        //  renderer.takeOverDisplay(myDisplayCallback);
    }
    else
    {
        writeError("Error %s", status.error);
    }
}

[davetcc]

Are we talking about just List menu items here? That may make sense thinking about it, these don't really have the concept of editing per se, but really it's a bug, as even changing to a new sub menu creates both an end and start event. I'll need to take a look at this in more detail.

[emaayan]

actually, it's something stranger, given this menu is used, i don't see ANY call for menuEditEnded being invoked.
even when i got back from the level of countries and cities to locations which is just the simplest menu there is

but going back does invoke the menuEditStarting, but it gives me a menuID of 50000 and it says it's menuBackLocation
so i'm thinking as this is the only way to go back i could use this as a trigger point to save settigns to eeprom (after checking the values have actually changed

menuShow.emf.txt

[davetcc]

Yes, I'm beginning to think that when sending the started notification, it should skip the back menu item (this is automatically created by the designer to allow you to go back), and actually return the first viable menu item, which is the one most users would expect.

The thing that concerns me is if anyone has relied on it being the back menu item now. I doubt it and you could be the first to notice this slightly strange behaviour.

In terms of the ended notification, I'll try and double-check all the places where a menu is replaced and see that there is an end notification there.

[emaayan]

don't dobut it;) , i'm using java GRPC framework at work, which has like half of it's api's and callback labeled as experimental, and i distinctly recall that switching versions once, suddenly stopped sending me callbacks that i relied it on and suddenly gave me uknown bugs ..

[emaayan]

Cool, thanks, let me know what you found. Cause currently those are the only ways I know on how to react to clicking on them to save to rom

…

On Fri, May 12, 2023, 19:28 Dave Cherry ***@***.***> wrote: Are we talking about just List menu items here? That may make sense thinking about it, these don't really have the concept of editing per se, but really it's a bug, as even changing to a new sub menu creates both an end and start event. I'll need to take a look at this in more detail. — Reply to this email directly, view it on GitHub <#352 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGP5MGXPUATOMSO4CSXNODXFZQKXANCNFSM6AAAAAAX7RKCZQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[davetcc]

I think the function for this that should have been exposed was ' void setupForEditing(MenuItem* item);' on menuMgr but it was protected. I've made it public now, and I think in 4.0 that will work.

[emaayan]

4.0? you mean version tcMenuLib 4.0? so i'll need to wait for it?

[davetcc]

You could try it yourself, the small part of the commit relevant to you is here -

TcMenu/tcMenuLib@6169c32#diff-cba81d0ad1d3a73d0a25d97f120e71a1a24cdf6ec9c3b86529155976616371a3R243

Just backup your tcMenu.cpp in the tcMenu library source, apply those four lines and check if it works. This would also confirm that when 4.0 comes out it will fix the problem. For clarity its lines 243-246 in tcMenu.cpp in that linked commit

[emaayan]

well i tried the change, and although ended does get called, it's only called right afterStarting, and it doesn't get called when i actually make a selection on the runtimeList