Submenu Entry-Action / Condition Check

[JanFeld]

Hi,

is there any possibility to execute actions / check conditions when trying to enter a submenu, like prevent going into the submenu if some conditions are not met yet?
Basically, is there a way to programmatically navigate through menus and trigger actions on entering menus?
Something like a combined execution of menu / command.

cli::Menu rootMenu = std::make_unique<cli::Menu>("rootMenu");
cli::Menu subMenu = std::make_unique<cli::Menu>("subMenu");

// Something like this for checks
rootMenu->Insert(std::move(submenu), [&condition](std::ostream& out) {
    if(condition)
        return true;
    out << "Do X before entering menu." << std::endl;
    return false; 
});

// or

rootMenu->Insert(std::move(submenu), [](std::ostream& out) {
    onMenuEnter();
    os << "Entering menu X" << std::endl;
});

Thanks for your answers.

[daniele77]

Hi @JanFeld ,
every Insert method returns a CmdHandler that you can use to enable/disable the given command.
... and guess what? a Menu is-a Command :-) The power of inheritance (not so cool anymore, unfortunately).
So you should be able to do something like this to enable/disable a subMenu:

CmdHandler  menuCmd = rootMenu->Insert(std::move(submenu));
...
menuCmd.Disable();
...
menuCmd.Enable();

(see the example complete.cpp, the colorCmd handler)

As for executing code when entering a submenu, I'm afraid there is no way right now. You can open an issue to request a new feature, however, can you provide some examples of using this feature? I believe entering a menu should be just a "navigation" operation, the user doesn't expect side effects when entering a menu, does he?

[JanFeld]

That's great, thanks for the hint. Could have figured it out by myself..
I think i can utilize that.

My Use-Case is the following:

I'm connecting with a device via bluetooth.
To be able to send some data or trigger actions it's necessary to be connected.
If the program is not connected it's not possible to run some commands.
Therefore a connect command has to be called to establish the connection.
Ideally the menu and the actions are not visible or usable unless the connection has been established.
Instead of hiding the whole menu it could be easier to check the conditions when someone is trying to enter the menue, e.g. if the connection is established and alive.
Otherwise the menu could call either an error-handler or show an error-message with the information required to meet the preconditions.
Hiding would possibly make it more complicated to understand and find the options, especially if the number of option grows.

Additionally navigating programmatically through some menus would allow for error handling like a connection-loss event.

I think it's easier to check/enable a menu and it's entries only if certain preconditions are met.
The above example using the CmdHandler can help me realizing this but is more about hiding stuff than error handling or directing the user the right way through the program.

Cheers,
Jan

[daniele77]

I understand.
However, I'm afraid it's not possible to navigate programmatically into a menu yet (I'm not sure, I should check that).
In your use case, I cannot understand the need to perform commands on a menu entry, instead. Do you intend to start the device connection when the user enters a submenu?

[JanFeld]

No not necessarily trying to connect during the menu entry action but check the conditions if the menu can be entered.

Another example would be subscribing to a service to receive notifications when entering a menu.
On menu exit unsubscribing would be kind of helpful too.

[daniele77]

I understand.
Well, currently there is no such a feature.
You could open an issue to request it.
However, you can consider subclassing in your code the Menu class and overriding Menu::Exec method so that it calls an handler when entering the submenu.