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.

I plan to make a series of youtube videos explaining a lot of hints and tricks

That would be absolutely great.

I'm planning to overhaul the getting started video soon, as the current one is based on 1.7 and so much has changed. After that I'll try and break up the hosting package so Arduino libraries and the rest of the site are separate, with the libraries documentation in a github public repo.

For low power, we prototyped it with SAMD, here's the example, it's easy to migrate to another board.

https://www.thecoderscorner.com/products/arduino-libraries/taskmanager-io/task-manager-low-power-samd-example/

Ah OK, I'll look at the documentation, and fix the issue. The long-term plan is to open source the Arduino libraries section of the documentation so it can be edited by others. I just need to work out a way to actually make it work.

In terms of filtering input something struck me, a textual menu item is nothing more than a multi-part editable item with a callback function that allows text entry. So for that, I could just have an extra edit mode of TEXT_CUSTOM in the drop-down in designer, and then instead of using the regular text callback, it would give you a custom function that would render it, using the name provided in the callback. This means that you can create your own input filtering and behaviour. Here's the text callback to see what I mean, this is the standard one:

https://github.com/davetcc/tcMenuLib/blob/master/src/RuntimeMenuItem.cpp#L310

and the docs on runtime items:

https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menu-item-types/based-on-runtimemenuitem/

Along with that, there is also the ability to have a commit callback, that could prompt the user and revert the edit too. See:

https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menumanager-and-iteration/

In terms of viewing and editing long items, I think theres two cases, slightly too long, where it could obscure the name slightly if needed, and far too long, in fact for the slightly too long case the name should have been fully obscured by the value, it was a bug that one rendered over the other, I've fixed it already.

For the very long case, I think I may have a solution based on the current list item support, but I need to think it through a little more. I'll feed back shortly.

So for example in menu it would show for example:

--- 8< ---- 8< ---
Item 1:         20394
My IP: https://thec..
Item 2:         20394
--- 8< ---- 8< ---
Clicking on the item:

--- 8< ---- 8< ---
My IP:
https://thecoders
corner.com/index.
html

[Close]
--- 8< ---- 8< ---

To be honest, up to now, at least in menus I've built, I've just avoided entries that are too long, but agreed, there needs to be a way of handling them.

Problem 1 - Value overwrites name when item is slightly too big, the solution is simple and can go into 2.4.1 due soon: I think that in this case, the best course of action would be to blank the area underneath the value, so the value takes precedence by clearing the name.

Problem 2:
How to present items that are horizontally too large, with this being the case, if the item were editable, it could be a bigger problem. This needs a lot more thought. Do you intend on editing values larger that can fit, or just present them?

If it is only to present such items, one option would be to have a menu item like a list, put a length-reduced version of the item in the menu, and when activated it goes to a list, and the list contains the full item broken over multiple lines. If it needed to be edited, maybe it could be edited one "part" at a time. If you think this could work, I'd be willing to have a go at adding it after this release goes out. It would be generally quite useful to have support for longer fields.

Many thanks for sharing the icons, they will be useful for others building battery-based applications.

Out of interest, if your system is battery based, did you try the low power support in task manager, where the call to task manager in loop tells you how long before the next task runs?

I've updated the docs to make it more clear that it is needed.

Ah, also make sure you

#include <BaseDialog.h>

in the file in question.

After upgrading to library 2.4, did you also upgrade the UI and run the code generator to ensure the plugins were up-to-date?

If you didn't want to do that, you could copy the same display plugin files from one of the examples, it would have the same effect.

I have created a better analog joystick plugin, and a new example to go with it, they'll be fully released in 2.4.1, but the plugin xml is attached, it may complain if you edit the threshold fields, but it should still generate OK. If you wanted to try it:

1. Before starting, make sure the tcMenu designer is closed.
2. Navigate to the following directory from your home directory, in a command prompt: ~/.tcmenu/plugins/core-display
3. Make a full backup of the current contents of any files you change
4. Replace "analogJoystickInput.xml" with the version attached here.
5. Start designer and the new analog plugin should be available as an input plugin from the code generator.

I'm assuming you've gone through the getting started guide already, if not probably the best start. The analog joystick is chosen during the code generation phase, the screenshot shows what settings I used.

At the moment there would be a couple of manual steps, but I think with minimal effort I can get the plugin to do everything, I'll have a go at the plugin today and see if I can get it to do back and next as well. I thought it already did but turns out it doesn't.

If everything is contained in the plugin as I expect, you could probably just drop the xml file in the right place once I fix it up and it would work even before the next release comes out.

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%.

Issues to track the other problems:

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


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

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?