Start a new topic

Editor 0.47 - how to specify a multi line string

e.g. if the MCU sends;

b0.txt="alarm\rcancel"

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


b0.txt="alarm\rcancel"

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.

image


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

   b0.txt=line1.txt+CR.txt+line2.txt


image


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.


Irrelevant.


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


image


In this scenario Alarm Cancel does not need to be written
Buttons have an .sta attribute that can be set at design time.
And perhaps much nicer than the default generated fonts.

Many paths to Rome.


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

Login or Signup to post a comment