The Sunday Blog

Thank you, dear attentive readers and users!

We, which means in this context, the Nextion developers, consultants, forum administrators, technical writers, and beta testers, are only normal human beings, like anyone else. Although we do our best, for example beta testing new versions of the Nextion editor, or developing example projects and code for this blog, to check and check again everything thoroughly, it happened (and will for sure happen in the future) that we oversee a little detail or a rare or specific use case. That’s why we are happy with and grateful for our attentive readers and users! In this article, I will cite two examples of how our readers and users help us making a good product still better.

Improvements on one side but regression on the other side in the Nextion editor

Remember when Editor v. 1.62.1 came out last April, bringing us the new TouchCap component which allowed us to write shorter and more efficient event code in many use cases? I wrote a rather lengthy and enthusiastic blog article about that, including – naturally – an example project. Afterwards, we got v1.63.1 which updated the Nextion firmware of the Intelligent series for using alternate flash memory ICs, due to the shortage of WinBond chips. My colleagues and myself did then multiple compile tests with pre-production HMIs using the new memory chips, checked timing and performance, tried to fill up the whole 128MB in stability tests, and so on. But nobody had the idea to re-check the touch component…

Feeling sure that everything was fine, we released v1.63.1. Until user Alody wrote in the Nextion forums that with this editor release, the TouchCap component would work well on the first page of a project, but it would take erroneous .val attributes and not the last touched component id when placed on the second page. Well, our developers found and fixed the issue quickly, and we got v1.63.2 within four days. Again, thank you Alody, for this discovery!

Volatility error in a blog project

Last October, I wrote an article about extending the functionality of components. The Nextion language not being object oriented, I showed how to obtain effects, similar to overloading objects, in a procedural way, using global variables. It was accompanied by an example project, showing how to transform a simple progress bar into an animated progress bar. That post had 689 readers since then, nobody complained (most probably, people use preferably the horizontal version of the progress bar), until last week, forum user SoloExEric commented in the forum that switching the progress bar to vertical would break the animation. While I was convinced that everything should work as expected, having switched many times between horizontal and vertical during the development, I re-opened the hmi file, ran the simulator, and – tadaa – SoloExEric was right. In the final version, in the very last line of the animation code, the x and y coordinates for drawing the background were switched. Shame on me – and huge thanks to SoloExEric for having discovered this! Here is the fixed hmi project file: animprogress_fixed.hmi_

The Nextion forum

As you can see, the Nextion forum is an important communication channel between Itead/Nextion and our users. We administrators (Patrick in Canada and myself actually in France) are listening to you 24h/24, 7d/7 thanks to the fact that we live and work in different time zones. If you haven’t yet, you are cordially invited to sign up and to exchange with other users and with us!

Thank you for reading and happy Nextioning!