Hello Dave!

Thanks a lot for this wonderful library, it made me experience the ioAbstraction lib too which is really useful.

May i give you some feedback and come at the end to my major roadblock:


I use TCMenu builder on OS X and the lib on Arduino Due (latest version for everything)

Hardware: Arduino Due, I2C 478x based 4x20 display, 5x4 matrix keypad




1. I found out TCMenu is crashing when you put in Divisor = 0.

2. Is there a possible way to detect if a value edit is complete? Right now i just get back every change, but did not find out how to detect if the edit is finished. Especially with keypad its a little bit cumbersome

3. I did integrate the keypad quite well (Ent = * and Esc = # and the up down keys for nvigation). Whats the best way to use the by tcmenu unused keys (like F1, F2, # , *) to trigger some actions?

#include <tcMenuKeyboard.h>
const char KEYBOARD_STD_5X4_KEYS[] PROGMEM = "WXYZ123A456B789#L0R*";
KeyboardLayout keyLayout(5, 4, KEYBOARD_STD_5X4_KEYS);
MatrixKeyboardManager keyboard;
MenuEditingKeyListener menuKeyListener;

4. Just a luxury question Is there a way to use the left/right arrow keys for navigating inside a edit field?

5. FYI IoAbstraction/TCmenu is not compatible with the Bouncer2 lib, if you have included this one too you get some wired behavior. I just encountered it when changing from Bouncer2 to your lib, so no real problem.

So, finally lets come to my roadblock:

I have a Menu wit Submenus, Analog, Action and EEnum working. Im getting the callbacks, it looks quite ok.

I can save the TCMenu settings to EEprom (i2C) wit menuMgr.save(eeprom). It works as expected.

But ... when i load the eeprom (no matter if i do it right after setupMenu() or later, TCMenu crashes the Due when accessing any menu where values are displayed. I can navigate the root menu but as soon as i go into a populated submenu or i select an ActionItem it stops the Arduino.

To experiment with that a little i did my own loader which takes the values from the EEprom and writes it into the TCMenu values

// its just one of the load commands, done for all values
stepmm = eeprom.read16(42); 
menuSettingsSetupStepper1mm.setCurrentValue(stepmm);

It seemed to work first but then it crashed again.

So i added just another second load for just 1 menuitem at the end of void setup(), which made it work again:

menuFlexWeight.setCurrentValue(eeval);

But it looks just like a happy accident, because when i change things in TCMenu generator and compile it again it crashes or it runs, with no pattern i can see.

As example, i added one more menu item, it works.

Then i added the callback function without code in it, still works.

Then i add the code and tcmenu crashes wherever i go (not only on this new item). It runs if i didnt load the eeprom values!

void CALLBACK_FUNCTION onFlexPresetChange(int id) {
  /*
  int swap;
  swap = menuFlexPreset.getCurrentValue();
  sermsg( 2, 0, "TEST: flex mode change: ", swap);
*/
}

The commented version above runs, if i uncomment it it makes tcmenu crash.

Btw. i did initialize the eeprom with 0 values and then a eeprom write via menuMgr.save, so the values from TCmenu look ok and i dont assume any problem from this side. Reading and writing to the eeprom also works like expected, so no I2C related problem.


It would be great if you can help me, i was hacking around the problem the whole weekend without managing to trace down the problem.

Tom

There's quite a lot there to go through, but in terms of the crash, it's because the EEPROM load function is wrongly calling the callback (too early in the cycle before anything was ready); which we are fixing in the next version. Given that the use case for eeprom load is to work at start up only, calling the callbacks is dangerous as they may rely on things being initialised. We'll do a commit onto master when we've tested this change, its lined up for 1.8 but you could just overwrite the file locally once it's available, fully backward compatible i think.

You can register a commit hander. Either a class that implements an interface or function, see: https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menumanager-and-iteration/ section "listening for changes".

Keyboard wise, I'll need to look in a bit more detail and get back to you about how you could extend the keyboard class, there are functions for next and back on menuMgr, I just need to remind myself how they would be mapped in to the keyboard class.

Except the eeprom related crash im not in a hurry

Im taking over the display quite often (renderer.takeOverDisplay(myDisplayCallback); & renderer.giveBackDisplay(); ) could this add to the problems?

Thanks!

The issue we normally see with eeprom loading is that it is done too early, before the application is initialised. This then causes a problem in one of the callbacks. Without any change you can make this less likely by moving load after setupMenu() and your core initialisation. We are looking at ensuring no callbacks are called during load as that would prevent these early callbacks.

Great, youre right. I moved it to the last instruction in setup() and for now it looks like it does the trick.

Does it have a influence on the tcmenu initialization if i take over the renderer before?

Right now i do:

void setup() {
   Wire.begin();
   lcd.backlight();
   setupMenu();
   renderer.takeOverDisplay(myDisplayCallback);
   lcd.clear();


   /* lots of initialization and hardware calibration code */

  lcd.clear();
  renderer.giveBackDisplay();
  renderer.setTitleRequired(false);    
  renderer.setEditorChars(0b01111111, 0b01111110, '=');
  setupKeyboard();
  setupSwitches();
  menuMgr.load(eeprom);
}

That should not matter much as long as it’s done after setupMenu, that’s the only limitation I can think of.

> 1. I found out TCMenu is crashing when you put in Divisor = 0.

Noted, we'll make sure this case is prevented in the designer UI

A little feature for the future maybe:

When you change the name of a submenu, it changes all the variables of the items in it. Little bit annoying if you just change a name and need to adapt the code then.

EDIT: i refer to the extern definitions: extern EnumMenuItem menuFlexPreset;

When you change the name of a submenu, it changes all the variables of the items in it. Little bit annoying if you just change a name and need to adapt the code then.

Yes, agreed, I'll try and get that one into the next release of the designer, that the menu name can be set separately. We have a couple of minor changes for the designer, so if this isn't a huge item, we'll add it. It hits me every now and again too, and a few others have recently asked for it..

Issue tracker: https://github.com/davetcc/tcMenu/issues/111

On the keyboard front, may be easier than I first thought if you are used to OO development.

In src/tcMenuKeyboard.h

You'll see that class MenuEditingKeyListener does the heavy lifting. You could extend this class, the two methods below are virtual, so could be overridden allowing you could check if a key needs special handling, otherwise call the base.

void keyPressed(char key, bool held) override;
void keyReleased(char key) override;

EG syntax may be a bit off but should give you the idea:

class MyKeyListener : public MenuEditingKeyListener

    void keyPressed(char key, bool held) override {
        if(special_action_needed) {
             // special actions here.
        }
        else  MenuEditingKeyListener::keyPressed(key, held);
    }

    // same for released if you need it..
};

Then use this instead of the regular key listener.

To do back and next functions, see the documentation linked further up, the menu manager documentation page describes how to do this.

Excellent, thanks a lot.


I found another note from myself which i made during experimenting with TCMenu, just as input

1. I think i did read somewhere that you have this already in focus, not sure:

When you jump back from a submenu you always revert back to the first item of the parents menu, not the item you have been

2. When you go down the root menu and you go past the last item, you start again on top at the 2nd item (my first item is e eenum field, didnt test if that matters)

3. Can the rotating feature (like described in 2) be deactivated?

4. Can the selector always be visible? When the menu is in stdby (without selector) and you click lets say down you "start" with the second item. When you press enter of course the first goes into edit mode.

5. and finally, i remember i did see it somewhere but cannot find it again. How can i change the menu timeout (before it reverts back to the root menu or finishes a edit)?

2. When you go down the root menu and you go past the last item, you start again on top at the 2nd item (my first item is e eenum field, didnt test if that matters)

I think that is a bug, we fixed a similar problem to this very recently, but if you can tell me the exact scenario, I can make sure it is fixed by trying that myself.

4. Can the selector always be visible? When the menu is in stdby (without selector) and you click lets say down you "start" with the second item. When you press enter of course the first goes into edit mode.

Not sure I quite follow?

5. and finally, i remember i did see it somewhere but cannot find it again. How can i change the menu timeout (before it reverts back to the root menu or finishes a edit)?

On the renderer object.

renderer.setResetIntervalTimeSeconds(seconds)

2: The cursor is off after the idle period. When you click on a number, you jump directly to that item. Wehen you press * the first item goes into edit mode. When you press # nothing happens. When you press "Up" you get the first field w. Cursor, when you pree down you get the second with Cursor. Cursor = Menupointer (in my case a arrow like i took out of one of your examples).

1. if you like i can mail you my tcmenu file

Btw. i have the title disabled