To get the currently active item you can use:

MenuItem* myItem = menuMgr.findCurrentActive();

There is no direct way to be informed of every change in terms of a new item becoming active. But what you could do is to take over the control of the primary encoder yourself (instead of using the plugin-provided primary encoder support), in that case, you would set the input plugin to no input required and set up everything manually referring to the guide below. Make sure the primary encoder is encoder 0. You could even look in the projectName_menu.cpp file to see what is put there by the code generator.

http://thecoderscorner.com/products/arduino-libraries/tc-menu/menumanager-and-iteration/#controlling-the-menu-items-manually

With that, you could change the precision whenever there is a new active item. Maybe it is that simple, there could well be a lot of edge cases that I can't think of, but I think you'd need to try it yourself.

https://github.com/davetcc/tcMenuLib/issues/145 already committed, will go in the next release.

Many thanks for working this out.

Ah yes, I can see why that fails now, we have probably mainly tested this case based around a BurrBrown volume control that has half increments, so falls into the decimal side of that if statement.

On the plus side, there are a lot of unit tests around this code, so I'll add another one for this case and then apply the fix. Thanks again!

Every now and again we find a bug with the analog support where a particular value seems to cause an overflow somewhere, although that range of values seems very small to cause this problem. Could you provide the divisor as well please?

I'll try and add the same item to see what happens.

I'll take a look at this and see what's causing it, as a temporary measure, you could try changing the selection background color in the theme file, it's never updated by the designer unless you remove it and force it to redraw.

You'll see something similar to "factory.setSelectedColors" in there that you can try adjusting.

In terms of the XBMP you must make sure if using gimp that the current image is monochrome first. Again there are many guides online for that.

As of the latest version you can register a menu manager listener. You can then control menu navigation as described here.

https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menumanager-and-iteration/#listening-for-changes-on-menu-manager

In terms of icons they use the XBMP format by default, you can export from gimp in that format. It basically saves an array of bytes that you’d include in your sketch. You’d then use these with title widget for display in the right corner. There is more on that here:

https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/rendering-with-tcmenu-lcd-tft-oled/

P.S. Something else: for "open recent" function ... it would be cool to see the full path there, not only the filename.

It used to do that, but we changed to use just the file name as it sometimes created very long paths that were difficult to read, but noted, I guess with duplicates it is difficult to know which.

I moved an old INO based project to PlatformIO.

Great, I use platformIO myself but with CLion IDE instead of VSCode. So as you can imagine, it is well supported!

Now in TCMenu Designer (OS X, latest version) i see all installed libraries as 0.0.0 installed. In general settings i unchecked "Im using Arduino IDE...."

If you don't have global libraries any more, just turn on the "I'm not using Arduino IDE option". These days, I question if the library checker is still even needed, all Arduino IDEs, platformIO and most mbed tools manage lib versions.

Pio is using the .pio folder in my project folder for the libdeps, all needed libraries are there. How do i tell TCMenu Designer to use this dir (its not selectable by GUI due to the .pio is hidden on OS X in the file select dialog)

As above.

in the output there is still INO mentioned, even when INO files dont exist

Ignore that, it's just the logging, assume it is referring to your C++ file. I mainly use C++ main for my own projects, other than examples. Even one of the examples, EspAmplifier uses a C++ main.

So from a quick look around:

* at least some STM32 boards have HID capability
* some Teensy boards have HID capability
* some Seeed studio SAMD boards seem to have HID capability
* probably most mbed based Arduinos (EG Nano 33 BLE)
* ESP32-S2 has HID capability
* [EDIT] Most SAMD based Arduino including MKR boards use cortex-0 with the ability to enter very low power states, even have an example for task-manager low power integration.


[EDIT] I wouldn't think of it as overkill, a cortex-0 is probably close to the same power requirement, with enough flash and memory to comfortably fit a large sketch. They are also all fairly inexpensive (some dirt cheap) and work with the Arduino framework.

Each key takes 10 bytes these days, the documentation should be updated, but it has been that way for a long time, ever since the onRelease functionality was added; when two extra bytes were needed for the pointer. So with 40, you'd need around 1600 bytes to store all those key states. I mean if the old version works for you, you could just stick with it.

I've noticed that one thing that was missed when moving to simple collections to do the allocations (which should have a very modest memory overhead) was the ability to set the number of switches upfront, meaning it will reallocate each time you exceed the current array, default start is 5 for AVR. I'll add MAX_KEYS back in the next version.

It is possible on such a small board that even 10 bytes per switch is too much, as even without the other overheads of the library that is already 1600 bytes out of 2500. To be honest, we've moved on and would not really consider an AVR in a production system these days, I keep the boards for testing with as I know many still rely on it. The power usage and price of much more capable devices have leveled out, and they are available in small pacakge configurations ready to put into a product. In terms of HID I think many STM32 devices can act as a HID using Stm32Duino. I also think ESP32-S2 does so too.

In terms of code being compiled out, the linker does that by default, only compiling in the parts you are using. It is probably simple-collections list accounting for the difference.

Task manager 1.3.3 was released yesterday, it contained a critical fix for event handling.

IoAbstraction 2.3.1 was released yesterday, it adds support for interrupt-based matrix keyboards. You can now choose polling operation or interrupt operation on either device pins or a MCP23017 device.

Compile error on mbed-based boards was also fixed.

Just out of interest, did you manage to get your project working on ESP32-S2?

This is a little outside the scope of the forum but I’ll do my best. The watchdog timer is to ensure that your code yields to the Wi-Fi library every few milliseconds. If you’re not using Wi-Fi one option would be to turn it off.

However, that aside you may need to transfer the serial data in smaller batches yielding between each batch. Maybe you could use a raw (not marshalled) interrupt and fill a circular buffer (SimpleCollections) in the interrupt with the data. Then have either a frequently running task or event that reads the circular buffer and sends data in batches. There’s no magic wand for these cases, but you’ll probably need to check if serial is going to block before calling write using availableForWrite.

Also if you’re using tcMenu with the u8g2 library over i2c ensure the low latency option is ticked.

2.3 has been fully released. Both Libraries and UI.