Based on the numeric keyboard example, I have created a message box widget, which overlays the page and tells the user whether his/her input is correct or not. This works fine. However the message text is set dynamically and could be quite long. 'isbr' of the message text element is set to 'True', 'xcen' and 'ycen' set to 'Center'.
For short text which fit in one line, it works perfectly! The text ist centered nicely:
+ Thanks! It's okay! +
For long texts, the text wraps around but breaks words, i.e. the text is broken in the middle of a word and not at whitespaces only. Also the text ist not centered anymore.
+ No, it's not okay! Pl +
+ ease correct your va+
+ lues +
I would have expected the ouput as follows:
+ No, it's not okay! +
+ Please correct +
+ your values +
Version of the Nextion Editor may play into for
- one version had broke \r but failed \r -non-issue in v.46
- .isbr doesn't mean "word wrap"
comes from br for break, meaning may contain linebreak
intent is: is .txt field to be multilined and may contain \r
Thus .isbr is not going to
- scan to locate whitespaces to define dynamic word lengths
and provide automatic linebreak parsing
Nextion has a small micro processor - not a word processor
This may indeed be mistaken by how much functionality has been
squeezed into the firmware already, still - don't take this for granted
If user is up-to-date having Nextion Editor v0.46 and
has re-read the updated Nextion Instruction Set then:
- there are several ways to achieve the desired effect.
In v0.46 one could actually scan for whitespace, a for loop, strlen and substr
and be able to parse the \r linebreaks in at the appropriate places dynamically
This would take a bit more coding, but could be done to achieve result
But most interesting is the method already used in describing the problem.
A small amount of calculation towards the static in the design time saves space
User knows width of char and width of text field - so derive max char per line
In describing the problem user padded spaces both sides to achieve centering.
There is either a small finite number of error messages that could be prepadded
such that when assigning .txt attribute it is already known to be precentered.
But in any way can be done with code Nextion side / MCU side.
Unless the details of each error is to be given on each error
The example provided can be reduced to a red/green tint .bco value for .txt
Such .bco uses much less code space when dealing with embedded devices