Hey Dave et al.

I'm nearing completion of my project and it has been an absolute pleasure working with these libraries. Everything I've wanted to do has been provided and any bugs I've discovered have been squashed! Thank you!

There are just 3 little things that I would like to tidy up and I can't seem to find good workarounds to 2 of them. The 3rd thing I believe is a bug, which I have shown a workaround for below (but maybe there's just a better way to avoid the issue in the first place). I can provide extra code if my examples aren't clear enough. I would appreciate any insights into these issues at your convenience. All issues are with latest version of TCMenu and compiled with PlatformIO for Teensy 1.57

1, Cannot select the default button in a BaseDialog screen
Not much more to it than that. I can put 0,1,2.... in the final parameter of my setButtons() function, yet the title bar is always highlighted regardless. Maybe something to do with manually controlling menu navigation with my buttons/encoders?

void CALLBACK_FUNCTION onDiscardExit(int id) { // Dialog to confirm exiting menu without saving
  BaseDialog* dlg = renderer.getDialog();
  dlg->setButtons(BTNTYPE_OK, BTNTYPE_CANCEL, 0); // <-- This number does nothing for me
  dlg->show(exitHeader, true, confirmExit);
  dlg->copyIntoBuffer("Discard changes?");
}

2, Doubling of highlighted items in BaseDialog screens
Again, using custom functions to navigate the menu. Problem arises when using the following code for a specific button in my onSwitchPressed calledback. If I've got anything other than the OK button (as defined in issue 1 above) highlighted, the OK button becomes highlighted IN ADDITION to whatever was previously highlighted. It's always the OK button, regardless of which I have chosen (as per issue 1.)

Back button snippet:

if (!menuMgr.getCurrentSubMenu()) { // In root menu?
     onDiscardExit(1); // Exit without saving?
   } else { // In submenu
     menuMgr.performDirectionMove(true); // Go up a level (this is what messes up the confirmation screen)
   }

3, Overflow issue when pushing big number into increment() while editing Large Number menu items.
Due to issues with needing FAST rotary encoder counting, I have the encoder connected to a secondary device (ATTiny85) which I'm polling over i2c to get my encoder counts when my main program (running on a Teensy4.1) isn't too busy. The function that gets this number uses some multipliers to allow for an accelerated input when turning the wheel fast. The problem comes when these big numbers are used while editing digits in Large Number menu items. I can get some kind of overflow which changes the digit into non-numeric values and even effects adjacent digits (things like: =>;: show up instead of numbers)

The code that was causing issues:

int16_t i = getEncoderAccelerated(); // Get encoder movement from ATTINY85 over i2c (usually around -512 to +512)
  if (i!=0) {
    switches.getEncoder()->increment(i);
  }

The work around (Any better way to handle this?) Seems like it should be constrained internally if big numbers cause this kind of problem.

int16_t i = getEncoderAccelerated(); // Get encoder movement from ATTINY85 over i2c
  if (i!=0) {
    if (menuMgr.getCurrentEditor()) { // If I don't confirm that I'm editing something the Teensy hard crashes on the next line
      if (menuMgr.getCurrentEditor()->getMenuType()==MENUTYPE_LARGENUM_VALUE) { // Check for editing Large Num
        i=constrain(i, -1, 1); // Solves bug where large num digits overflow from fast encoder movement.
      } 
    }
    switches.getEncoder()->increment(i);
  }

I hope this all makes sense and can help you make these great libraries continue to improve. Please let me know if there's anything else I can do to assist in resolving these 3 issues.

Many thanks for the feedback and working out where the issues are, it's always good to hear how tcMenu is used in real situations.

Once I've got the current release out the way, I'll take a look through these and fix them up.

Excellent, Thank you!

Update:
I just saw that tcMenu 2.4.0 is out. I went ahead and updated that (along with IOA)

Issue 1: Improved in that now it always selects the OK button instead of the title bar, but still doesn't seem to allow me to change the default

Issue 2: Still exists, but is less obvious because of the new behavior of Issue 1.

Issue 3: Seems unchanged. My workaround still works just fine.

----

Bonus Issue 4: Absolutely LOVE that values of 0 in Large Number menu items don't show up empty anymore, and I like the underlined digit indicator better than the way it was before, but the alignment of that indicator seems to be off. In the attached pic you can see that I'm currently editing the left-most digit (2) and the indicator isn't really under that digit. This continues all the way to the last digit where the indicator is off to the right, and pushes all the digits a bit to the left. I tried changing my margin settings thinking that maybe it was expecting the default values, but that didn't seem to help.

3, Overflow issue when pushing big number into increment() while editing Large Number menu items.
Due to issues with needing FAST rotary encoder counting, I have the encoder connected to a secondary device (ATTiny85) which I'm polling over i2c to get my encoder counts when my main program (running on a Teensy4.1) isn't too busy. The function that gets this number uses some multipliers to allow for an accelerated input when turning the wheel fast. The problem comes when these big numbers are used while editing digits in Large Number menu items. I can get some kind of overflow which changes the digit into non-numeric values and even effects adjacent digits (things like: =>;: show up instead of numbers)

For this it is actually the encoder's responsibility not to overflow, you must make sure that the change in value passed to the menu manager never exceeds the current maximum value, which you know from the last time menu manager set the allowable range.

If it is increment on the encoder class we are talking about, that is pretty simple https://github.com/davetcc/IoAbstraction/blob/master/src/SwitchInput.cpp#L316

Or is there something I'm missing here?

Issues to track the other problems:

https://github.com/davetcc/tcMenuLib/issues/155


https://github.com/davetcc/tcMenuLib/issues/154

Thanks again Dave!
I'll keep an eye on the Github issues.

For the encoder overflow, since I'm not actually using IOA to get the encoder values, I expect I just need to continue using my workaround to make sure I don't exceed that increment number, but I'll look into checking the allowable range/maximum value to see if I can make the workaround a little less clunky. Thanks for the tip!

As always, please let me know if I can provide any further info to help nail down the other issues I'm seeing. I'm happy to help where I can.

I think I've got most of them now, the only one left is multiple active items in a dialog. I'll get that one next.

The new focus now is to fix any bugs and make the library more workable, with even more hardware and platforms than presently supported.

Apologies to all for introducing another bug with cursor positioning, but the square brackets around the editable item were causing problems all over the place (even in IoT arrangements because the value of the item contained them), and further when combined with a matrix keyboard things got messy. I'm going to double down on that before the next release and make sure it's 100%.

Wrong or two items being active:

The good news is that I've finally tracked down what was causing most of the problems with the wrong item being highlighted, or even two items being highlighted.

It was one of those moments where once I saw the wrong code, it questioned how it could have ever worked!

Anyway, thanks for helping me track this down, and it will be fixed in the next version.

Cursor problem:

Other than the known problem with positive only large numbers which probably affects everything. Seems very dependent on the font/driver. I can't get it into the wrong position on the U8G2 demos, but it sometimes a bit out with TFT / proportional fonts.

Haha, I have those moments when I'm programming all the time (although, in my case things bug out and I wonder "how did I ever think that would work!?".)

I don't know if it's helpful, but I did attach the font file I'm using since I have edited some of the characters to display custom icons or characters that aren't in the default font (specifically: ~!@#$ have been changed.)

I'm using a 3.2" 320x240 ILI9341 display module.

The only other change I've made is to adjust the padding in the generated ThemeCoolBlueTraditional.h

MenuPadding titlePadding(5); // Custom padding 
MenuPadding itemPadding(3,10,2,2);  // Custom padding

This may be at fault (?)

Thank you very much for posting all these updates. All your hard work is greatly appreciated.