Yes, you can.
Does this even work? Because I'm trying and it doesn't appear to?Can you give an example in code?
Thanks Monoszs , it works. "\r" instead of "\n" then.
Confirmed \r works for button also, as in b0.txt="alarm\rcancel".
However, can not set same string in editor so button is initialized with this string.
String is accepted in editor but printed in one line.
Same problem with text objects.
Also, while xcen=center, the 2nd line is not centered.
one only needs to break down the problem into achievable parts
and then build a multipart solution using these parts.
Line centering is also achievable by user code
total width of component, width of character, width of line (charwidth x qty)
add spaces where needed
Nextion's onboard MCU will not perform word processing.
Sorry you seem to misunderstand me. The first point of the request is to have the hmi static setting support the \r feature, the same as sending the data from the MCU. Some text and button labels are static so should not need to be managed by the external MCU. In general the editor supports this principal well, this is a small area for improvement.
"Nextion's onboard MCU will not perform word processing" - you have a rather aggressive attitude to paying customers taking time to provide suggestions which could benefit all. If you offer an alignment feature, and it turns out support multi-line strings - great, the alignment should work for all lines not just the first one. This should not be hard to implement.
Due to this (small) limitation, my user's editor static button and text lines must be confined to single lines.
This forum is public community support. First and foremost I am a Nextion user of this community. So you are no more a paying customer of mine than I am a paying customer of yours - well, perhaps until you have at some future point actually paid me, then your status would of course adjust.
\r has been implemented.
(check feature request status at top of the thread page)
in one version of the Nextion Editor there was indeed a bug, but since fixed
Your expectations of "me" to bend to what you want because you have purchased such an awesome device at a better than fair price and still like to have it perform more without needing user code - is perhaps unfounded.
So, I will evaluate the user request and make my recommendations
- obviously, the more votes will have some secondary influence
- opened by user twenty-one months ago
(who didn't realize \r was already implemented)
- zero votes out of 25,000 registered users in 21 months.
But perhaps more important in my recommendation considerations
- focus on the development of Nextion as an HMI device
- protection of the limited firmware space.
- avoid firmware bloat for function achievable by user code.
As told this can be handled in code,
and I even told what is needed to consider to achieve it. ;)
Multi-line alignment .... is indeed word-processing.
Your static button does not need be limited to single lines
So since an MCU will only do exactly as instructed to do,
one only needs to exactly tell it what you want to achieve.
You must only write the additional code.
This can indeed be achieved in Nextion logic - no external MCU.
and you are right - this is not too hard to implement - in user code.
- but indeed not via firmware bloat.
Perhaps make a list of the functions that you are willing to give up
in firmware and recommend your word-processing multi-lined button
and see if the community will vote support for your recommendation.
But I do indeed represent all user requests, every single last one of them
No need for sugar coating ...
We are talking about programming MCUs in confined SRAM spaces
So to even to use Nextion, you are generally utilizing an MCU
- and this user chosen MCU that you use has itself limited capabilities.
The deeper you understand the programming of an MCU at lower levels
the more you will come to understand your Nextion
(which itself has an onboard MCU 8K/64K or 20K/128K depending on model)
But MCUs are exacting .. there is little reason to sugar coat - your MCU will not.
And it would make no sense for me to provide false hope
only that you have a feel good now, disappointment later is much worse.
An MCU should be purposefully programmed
what is not programmed purposefully will perhaps not render desired result.
But Nextion as an HMI device is also not an MCU replacement,
- users duty to select 1 of 63,000+ available MCUs
that best fits the needs and requirements of their project.
The onus of project logic is not push onto Nextion - MCU should remain in control.
The only reason I can think to push this into Nextion firmware is that the user side MCU is not capable of performing the task. But this then bounces back to the user's onus to select a proper MCU for their projects requirements. Selecting a PIC12F629 and claiming HMI device needs to be responsible for word processing because the PIC is not capable is not a good enough reason when user had responsibility over selection.
Human Machine Interfacing
an interface for presenting user choices and input
Nextion then makes an MCU request (MCU should always maintain control)
MCU decides if the request is valid and safe to do so
MCU to perform request if/when it was safe to do so
MCU provides user status/progress as to their request.
So, Nextion is not going to be a word-processor (unless user programs such)
it is not a phone/tablet/desktop/server/multimedia replacement
Multi-lined button code
- can indeed be implemented in Nextion Logic alone
- can indeed be handled by the MCU side code
But such coding discussions are for the Free Chat section of the Forum
and not at the bottom of a nearly two year old closed "Implemented" thread.
I am now reviewing all of the Feature Requests, this will take some time, patience please.
Further work on the escape sequences has been done
Further work on the escape sequences needs to been done
Partial implementation - carried forward
Wow. Ignoring the diatribe and focus on this statement;
"This can indeed be achieved in Nextion logic - no external MCU"
Super. Please indicate what to enter in the 0.47 editor txt field so that the \r works and two lines are displayed. I guess it's too much to ask that the center feature work for other than the first line but users can experiment with padding spaces to work around that I suppose.
e.g. equivalent of this string from an MCU;
Perhaps open the question in Free Chat
- then all in the community can benefit from
No one will look in an Implemented old thread to find their solutions