Constrain navigation, or make item non-navigatable.

[futurexdesign]

Another hopefully "simple" question.

Is there currently a way to make a menu entry "output only", or otherwise non-navigable? The interface I am doing is outputting a formatted timer above a row of buttons. Ideally, I would like to be able to constrain the navigation to just the grid-row while on this home-screen, as if the timer output menu item and title bar didn't exist on this screen.

From reading the various documentation pages, it looks like I might be able to hook into MenuManagerObserver , and perhaps manually move the selection back to where I want it, ignoring the presence of the timer menu item. This doesn't exactly seem straight forward, but if that is the suggested route, I will go down that path. If you haven't already noticed, I'm trying to avoid breaking out and having to manually render things as much as possible, though it seems using a Dashboard view might also be an option?. Ultimately I need most of the menu system for the settings/options menus.

UI Screenshot for context:

[davetcc]

I think what you're looking for would align perfectly with the new dashboard with button support that is coming in 3.2. It allows you to do exactly what's there and there's even an example that pretty much does what you're doing there. This requires 3.2 of the library though:

https://github.com/davetcc/tcMenuLib/blob/master/examples/arduino32/picoAdafruitDashboard/dashboardConfig.cpp

In terms of the observer, I would also think it to be straightforward to achieve this result, whenever the title item or clock item were activated, move the active item to be the first action item. The dynamicMenuItems example shows how to use the observer.

https://github.com/davetcc/tcMenuLib/blob/master/examples/arduino32/dynamicMenuItems/dynamicMenuItems.ino#L92

[futurexdesign]

Thanks for the follow up, it is much appreciated. I’m a backend developer by trade, so this ui stuff is always an adventure for me.

The one issue I had while playing around last night is that when I tried to move the “cursor” by calling “navigateToMenu”, the interface would switch to rendering the menus as text instead of icons. I’m not sure if I’m just calling the wrong method? I can sort of understand why it might do that, as I assume it is re-rooting the tree to the selected menu item, but I’m not sure what to call instead to move the cursor while keeping it in the button grid view. I didn’t seem to find any appropriate calls in the documentation.

[davetcc]

Can you debug the board or put a few log statements around that to see where it is going wrong? Ive recently tested that sketch in its Adafruit variant and that worked. But that was some weeks ago and changes have been made since.

I’ve only just started stabilising the libraries for 3.2 having done the UI. if you use the overnight library you probably also need to use the beta UI. I’d recommend that you hold off on that while it is tested a bit more.

[davetcc]

Just a thought - my first guess would be are the fonts you’re using in the dashboard compatible with the library? IE with whatever you have configured.

[davetcc]

The one issue I had while playing around last night is that when I tried to move the “cursor” by calling “navigateToMenu”

Ah yes, navigate to menu should only ever be called on the first menu in each group. It's a bit legacy now in how it works, but all menus in TcMenu are single-linked lists from first to last. So to present a menu we simply pass the head of the list. If you were to pass another item instead it will present only the items from there.

Not 100% sure, as not tried to activate another item from the activate callback, but I think you want to deactive the active item and activate the new one and I'd try this first:

bool activateMenuItem(MenuItem* item);

EDIT - and that is on the menuMgr object.

[futurexdesign]

That is interesting. I tried making a quick observer as such:

void MenuChangeObserver::activeItemHasChanged(MenuItem *newActive) {

    Serial.println("Active menu item changed.. ");

    if (newActive == timerRow) {
        Serial.println("Tried to move to TimerRow... Move back to LeftConstraint ");
        menuManager->activateMenuItem(leftConstraint);
    }
}

Basically saying, if the active item changed to the row above my icons, switch it back to the left most menu in the grid row. This, sort of works, but seems to conflict with the encoder state tracking.

I get that I'm operating outside the bounds of what the library is "meant" to do, but I'll outline what it actually does for the sake of completeness.

When you rotate the encoder and it steps "up" to the timerRow, the observer is triggered, and my if is true, the left most actionMenu is set to active (it stays highlighted in the UI). If you click the encoder button, it works as expected, and the selected action menu is triggered.

Where it gets into an odd state is that now, if you rotate the encoder one step "up" again, you end up on the TitleBar. It also takes two "down" pulses of the encoder to move the active icon to the next button in the grid row. Without looking through the library code I assume this is because the encoder state doesn't change to reflect the fact that I moved the active item on the screen, so it continues to step though as if the active item was still the timer row.

Not sure if that is worthy of a bug or not, I can probably find a way around it with some more trial-and-error.

[davetcc]

I think this is the bug I fixed today in the library. See recent issues in tcmenulib

[futurexdesign]

That certainly sounds like it. Thanks so much