I have a small screen to work with. When using text fields, if the value entered is too long, it writes over the top of the field name.
As an example:
Server: https://www.someserver.com/mqtt
so https etc would be written over the top of Server

To make matters worse, if its too long, the right side is off the right side of the screen.

Any ideas how to solve this?

Strategies I have thought of but have no idea how to implement:
1: "dual line" the field somehow. For example adding a text entry above with the name "Server" but the actual field entry is a text entry below.
Obviously this field has to be named. But I would at least need to be able to not display the name in the menu (such that the long text entry can occupy that space)

2: some form of scrolling text for the entry, which is blocked on the left side, just past the field name text.

Has anyone else had to solve this problem before?

edit: attached an image

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.

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

I like the blanking out idea.. That could work if I insert a "useless menu item" above it to act as the field name (fake name, not the real one).

So more detail on my use case:
As you can see from the image, Im using one of these surplus smart watch screens.
There are one or two other fields with this problem (and I would LOVE to avoid menus with them, its just not practical unfortunately).
This particular use case is to enter a mqtt server address. When it was by IP, it JUST fits in (In fact, I changed the field name to just "server" to let a 3.3.3.3 address fit)
But then the guy setting up our servers mentioned I should probably use the domain name..
And now we have this long "https://longdomainnamehere.com" sort of problem.
If I were only displaying it, I could still work around that somehow.
But I intend that after the event is finished, people could edit and re-point the device to their own server (hence editable).
I suppose one solution is to make that editable over the serial port instead. I was planning to make some sort of serial terminal menu anyway.

Not to push you to develop anything, but sure I think long term feature request would be:
- entry fields have a method to detect if its too long for the screen space and then do some sort of scroll or A/B flipping when highlighted.
for that to work though, there needs to be a method to know where the end of the field name is on screen, and clip the value there.
Or perhaps its more accurate to say "the entry field space ends here."

The other thing I have not looked into yet is dialogs. If in TCmenu speak, that refers to something similar to a dialog box desktop code, then perhaps text fields could be edited such a dialog box rather than directly in the menu.

I am considering that I may need to do some text validation anyway, and was considering using renderer.takeverdisplay() on edit for those fields and draw a custom text entry tool, which forbids the various characters as required.
TBH I absolutely love the menu system.. theres obviously so much work that goes into it. But the method for editing text fields using a joystick is a bit tough for something like a url or password. The built in scroll acceleration certainly helps.
I say this though, knowing that I cant think of a better solution to propose :/

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.