\r \" and \\ are the only currently supported escape characters
Such is supported over serial.
Although \r will create multi line, it does not look after all possibilities
such as word breaks and centering of each line of the multi-line .txt
another point to consider is just your used font. Not every font behaves same in terms of wordwrap and line breaks within a multiline text ....
adding an additional space at the right position can help ...
There was indeed a bug in older versions with \r
Such bug was fixed in v0.46 and now works as shown above
so you can no longer use "\r" control code in the printf function to produce a carriage return, line feed.
to get it to work you have to use "\\r" in the printf function. the first 2 \\ produces the single \ and then the r which the display interprets as its own control character.
So the display display does not recognize a hex 0d - as produced by the \r in the printf function. only an ascii '\r'.
Your statement "so you can no longer use \r" is incorrect.
I have already shown its use case where it works.
what I was saying is the control character \r in a printf statement will not work, you are sending the ascii string'\r' in your example above.
Nextion is not driven by a single programming language, for a single compiler, or single library of functions.
printf and its limitations has no bearing for Nextion
Does not matter how your language generates the proper required sequences
- what does matter is Nextion receiving the needed sequence, triple 0xFF terminated.
Correct. Hex 0x0D was never accepted as textbased "\r" replacement.
The .txt attribute is a string, array of char (not really, an inaccessible array).
.txt is generally expected to render into graphic representation on the screen
as chars 0 to 31 are non printable, there is no provision for in the zi font matrix.
ORD(char) - 32 becomes position in font to font matrix data.
So first char in font file space character, char 32, first matrix (preview font in Editor)
0x0D has no matrix, is in ascii terms unprintable.
minimal provisions made (in tight MCU space) to provide exceptions
- support for \r exception is created
- support for \\ and \" is expanded
- no other escape sequence provided for.
But the nature of the small Nextion side MCU need be taken into consideration
- it is just a small MCU tasked with also running user generated HMI
- it just can not hold all possible cases, its just a small MCU