e.g. if the MCU sends;
the \r is interpreted so 2 lines are displayed in the text or button object.
However, if this same line is entered in the 0.47 editor for the initial setting of an object, in sim or on target a single line including the \r character is displayed - as you see above.
How then to get the 2 line behavior when using the editor?
don't set the content of your variable via property panel ...
set your variable directly via command in your PostPage action...
I had suggested breaking the problem down into achievable parts
then building your compounded requirement from those parts.
Native alignment - already aligns - but indeed not in 1/2 characters.
Breaking down the problem is:
each line's content is known before needing to join
lines are joined by a two char "\r"
line1.txt="alarm" // static or dynamic
line2.txt="cancel" // static or dynamic
CR.txt="\r" // static set in preinitialize
Then rebuilding from these parts
In centering better when purposefully adding spaces
- line1.txt="alarm A1" // 8 chars
- line2.txt=" cancel " // 1+6+1 chars
- the largest will be centered, thus adding 1 leading space does it.
- but again such is not going to be centered to the half character
Now if centering was wanted to the half character
- the width and height of the font character is known to the designer
- the width of the txt is known strlen x charwidth
- the width and height the button is known b0.w and b0.h
- the start top/left coordinate of button is known b0.y and b0.x
- center horizontal add spacing of (button width - text width) / 2
- center vertical add spacing of (button height - (lines x charheight)) / 2
Nextion provides xstr command for dynamic precision placement
- then simply xstr the content of each line for precise placement
But honestly, +/- 1/2 a character in centering serves most
- all needed commands are in the Nextion Instruction Set
Thanks for the detailed work around for the basic issue that a static attribute of a multi-line string is not currently supported in the editor/firmware.
Regarding pixel centering vs character centering that would be a nice firmware enhancement that hopefully would not consume much if any additional rom since the work is already being done at the character level.
The xstr command is already in firmware.
I might also argue, programming is not "a work-around", but programming.
Sigh. I'm not, as you imply, trying to avoid programming. I'm doing an plenty of programming to support this display on the MCU. It is a pity I have to instruct screen designers (who are not programmers) using the Nextion editor not to put multi-line statements in the static attributes which is obvious and logical (and woks nicely for single lines), but to learn this work around.
It doesn't matter what text is statically put in the .txt attribute at design time.
An MCU command to change said text will override.
But programmers should be the ones to handle logic - not the artist.
A good graphic designer can design multiple "buttons" with the needed text graphically
- these graphical buttons can then be used - much nicer than a 1980's gray with poor font.
A matter of assignment of duties
Most times all that is needed is more imagination.
Creative duties to the Creatives
Logic duties handled by the Robots
Alarm Cancel does not even need to be written
Perhaps more universal and not bound by English language is symbols
"many paths to Rome" - but not it seems ones suggested in good faith by customers.
I appreciate the alternative suggestions, I do NOT appreciate the attitude.
In all seriousness - which do you prefer
... to be able effectively use the product you have?
... or the knowledge that maybe some future generation has an ability yours don't?
I won't be the guy that says
"Thank You for your valuable input." without meaning - and nothing occurs.
I'll choose to be frank .. your MCU will be absolutely frank.
- Basic and Enhanced models will 99.5% most likely not get such upgrade.
- existing customer needs to be able to use the device in hand
You're a microcontroller programmer .. so it's simple logic
8192 bytes of SRAM space on Basic model - 3584 bytes promised to user HMI.
- doing the simple math of subtraction - 4608 exists for firmware
- going above 4608 bytes of firmware steals into the 3584 bytes promised to user HMI.
So to expand firmware (by bloating it) for such a recommendation
- would leave making a new series with a larger MCU on the Nextion side.
And this option would no way upgrade the device you have in possession.
Programming MCUs are fairly cut and dry, pass/fail, 1/0, works - doesn't.
So as far as the suggestion, you needed to know how to do it. Told you how.
Out-of-the-box canned behaviour is above. Use xstr for precision.
This conversation may be different from an experienced graphic designer
- they would have suggested to use the whole screen graphically
- where font would look better
- anti-aliased and smoothing
- Variable width fonts being used - vast 1200% more font's to use
- beautiful creations in their favourite professional graphics program.
But I'll choose to be frank and honest with the community members
And in doing so ...
perhaps assist you to get the most out of your existing investment in Nextion.