Hello

I'm try to learn how tcMenu works by doing some examples.
The problem I have right now is following.

I try to set a value to a EditableLargeNumberMenuItem, in my case called menuRotation.
When I set the value 3.2 with menuRotation.setLargeNumberFromString() I got 3.0 on the display.

I try also to set the value 5.5 to a AnalogMenuItem, in my case called menuAnalogItem with menuAnalogItem.setFromFloatingPointValue( 5.5 ) I get 5.0 on my display.
Why is it like this??

I'm testing on a ESP32 and I using the latest version Arduino IDE, tcMenu and tcMenu Designer as well.

Unfortunately, there is not enough detail in this request to be able to determine what menu structure you have. As per the GitHub site, when raising issues here always include the menu definition file that you generated and any relevant sections of code. This forum is realistically kept running through the help of volunteers, please help us by providing complete isolated examples.

Ok! It was very late yesterday so I missed some details. Today I have started from scratch, made a new mini project that shows my problems.
The main goal with this, is that I try to understand how to work with tcMenu, so I can use some project afterwards.
In this test project would I like to set start vaules to the menu variables at start up, and even readout the setted vaules.

This resulting project, including 2 readme textfiles, have I compressed into attached "MenuTest_5E" zipfile, even including pictures showing the display.
In the file 'ReadMe -Faultvalues.txt' I have described what is done and referensing pictures.

In clear text here, is as follows:

1. Readout value from a EditableLargeNumberMenuItem with Callback shows under some condition wrong value,

2. AnalogItem looks "funny" when it not has Focus,

3. When setting a EditableLargeNumberMenuItem, it don't seems to get the decimals, setting 3.1 gives result 3.0 at display,

For the last point #3, I belive there is a better way to set the value, but this way was the only one that worked for me.

A fourth point could be a question, how can I notice when display has "timeout'ed", and is there a way to change this timeout time in my code ?

My programming knowledge is a little bit limitated, so I is open suggestions for better code writing.
I look forward to any answers..

Many thanks for the detail, I'll try and run your menu up this afternoon and feedback with more information.

However, after looking at the images, I think the strange coloring of the analog items is caused because the renderer has flipped to using XOR drawing. May be worth checking you have one of the mono themes installed within the code generator dialog.

After have away from this project some days, i made a new try yesterday. Onething I didn't try before, was to add a theme. It made a change to my point 2, so the Analog item was readable even when not having focus.
Later on this evening, I can give more details about what I was doing...

SO, I have made some more tests.
My focus this time is on point 2 - rendering AnalogItem.
When I add some theme, then it looks OK. To try find what is making the difference I included a theme and then afterward disable row by row. At the end I find two rows that make differense.

In the file *_menu.cpp, (in my case "MenuTest_5E_menu.cpp"), is the function setupMenu(). If I add the following rows in the end of the function, then looks the rendering of AnalogItem OK.
The "magic" rows are

renderer.setTitleMode(BaseGraphicalRenderer::TITLE_FIRST_ROW);
renderer.setUseSliderForAnalog(false);

EXACTLY what they do have I not checked up, I just found that they make the display looks OK.[b]

Basically, without a theme the display will not be properly set up, the designer should probably complain if there is no theme and one is needed.

Thanks for the detailed report, I can see there is a problem with the decimal precision of large number items when set from strings. I have not managed to find a workaround unfortunately, I'll look to get it fixed in a patch shortly.

https://github.com/davetcc/tcMenu/issues/183 this is to warn the user is a theme is not selected when one is really needed

https://github.com/davetcc/tcMenuLib/issues/134 for the large number bug, thanks for reporting in such detail.

The large number bug has been found and was very specific to the 1 decimal place case, there will be a 2.2.7 release of tcMenu coming shortly, that will:

1. fix the large number 1dp bug
2. make sure that users cannot proceed to code generation without a theme selected when one is needed.
3. move onto the latest OpenJDK 17 for the designer UI.

All in the process of being released now.

At Tuesday I downloaded the updated library and the new version of TcMenu Designer. To test I remake my testprogram, (MenuTest_5E_New), for new tests.
In the updated library I also notised an updated example program, esp32SimHub, and here I found new ways to set value to a "EditableLargeNumberMenuItem".
I tested 2 different calls, A/ setFromFloat() , and B/ setLargeNumberFromString().
For storing my value I used a float varaibel fRot with value 3.1.

With the A/ setFromFloat() my display was showing 3.0, and when using B/ setLargeNumberFromString() it was showing 3.9.
I found it very interesting to find the reason, (and of course to learn more from using C and C++), i find it after a couple of hours.

In the attached zip file "MenuTest_5E_New.zip" I have included a file "Comments_tcMenu_2022-02-17.pdf" where I explain what I found and my solving suggestions.

Many thanks for testing this again, and for the pdf with the problem described. It really helps me to track down the problem.

There were many unit test cases around the editable large number class, but none of them originally tried with 1 decimal place. I'll go through these additional places and fix them up shortly. In fact, I'll go through all the test cases and make sure 1dp is tested everywhere. With floats, because of the binary nature of them, 0.1 and multiples of is not represented particularly well and will be slightly below or slightly over, a bit like 0.3333 recurring in decimal. I think the solution you suggest in the document is good and will try to put it in shortly.

Many thanks for this and for the suggested fix, both problems are now fixed.

I've made the changes locally and will get them released shortly.

I've added even more automated unit tests that capture these additional cases too, so hopefully, they will stay working.