The Sunday Blog: Breaking news
The new Nextion Editor v 1.62.1
Actually, the breaking news don’t stop! After we got new very powerful Intelligent HMI displays in 4.3″ and 5″ format (see last week’s blog), we got also a new release of our Nextion Editor. Besides support for the new displays, it brings us a few bug fixes and a new component. The latter is available to all displays, the Nextion Standard (T), Enhanced (K), and Intelligent (P) HMI displays. We will look at all this in detail one by one.
Improvements, fixes and changes
On some Intelligent HMIs with resistive touch screen, touch stopped responding after very long uninterrupted runtime > 7 days. This is now fixed.
The behavior of the vis command has been improved. Before, when you hide a component with vis xy,0, in its place, the initial page background had been shown, even if it had changed in the meantime. Now, it’s always the actual page background which replaces the hidden component. Huge thanks to forum user Max who reported this.
On some Intelligent HMIs, changing the file path of an audio or video component at runtime (from code) would give unexpected results. This does not longer happen.
Although the Nextion Instruction Set has been stating for years that only ascii characters are allowed for component, variable, and attribute names, previous editor releases were somewhat tolerant and allowed for example page names like page_éphémère for French or page_Çay_bardağı for Turkish users. From now on, such names will throw a compile error and you’ll have to rename your components, variables and attributes without special characters.
Listening to our forum user base helps making this product still better – always within what is possible with respect to the limits of available memory for firmware and user code. When we look at this list of fixes and improvements, we see that the Editor is very mature for the Standard and Enhanced HMIs and that the developers are eliminating the last little childhood diseases for the Intelligent HMIs.
The vis command improvement requires a small firmware update on display side, so don’t be surprised when the first upload with the new editor takes 3 more seconds.
The new TouchCap component
TouchCap is short for Touch caption. Adding a TouchCap component to a page will allow to add common event code to all or only selected touch and release events. Out of that, its .val property (read-only) will always hold the id of the last touched component. That will greatly ease the developer’s life when you have for example many buttons on a page, all with similar event code. From now on, you may leave the buttons’ event code empty and put common code in the TouchCap’s event code windows. To distinguish which button has been pressed, it’s as simple as getting its id by reading tc0.val.
Caution:
1.) Although the editor allows to put multiple TouchCaps on one page, this doesn’t make sense. Only the one with the highest id will work as expected, the lower ones will only eat memory without ever been triggered.
2.) There is a little visual flaw. The event code panes for the TouchCap show actually still the “Send component ID” checkbox. If you check it accidentally or intentionally, nothing will happen since this makes really no sense. Once you change the pane, it will automatically be unchecked again.
How does it work in detail?
Step 1: Component XY is touched
Step 2: Component XY’s id is sent (only if enabled)
Step 3: The TouchCap’s val attribute is set to Component XY’s id
Step 4: The TouchCap’s Touch Press Event code is executed
Step 5: Component XY’s Touch Press Event code is executed
Step 6: Component XY is released
Step 7: Component XY’s id is sent (only if enabled)
Step 8: The TouchCap’s Touch Release Event code is executed
Step 5: Component XY’s Touch Release Event code is executed
How can it be used?
It is intended to handle similar events from different components in a similar way. It may make such coding and maintaining easier. I have prepared a little example below.
The example
Let’s imagine a little number guessing game: A hidden random number between 0 and 9 is to be guessed by clicking on one of ten buttons, numbered from 0 to 9. When clicking the correct button, the hidden number shall be displayed in green as a success confirmation. When clicking a wrong button, the correct number shall be displayed in red as a fail notice. In ever case, after each try, correct or wrong, a new number is to be generated and the game starts again.
Doing it the classic Nextion way, you’d have event code in each button, comparing the hidden number to 0 in the “0” button, to 1 in the “1” button, and so on. Then you’d have 10 times almost the same code for unhiding the number and for coloring it green or red, depending on the value.
With the TouchCap component, we need code only in one place, the buttons’ event code remains empty! We just need to take care that the id values of our 10 buttons are consecutive. In the example HMI file, they are von 2 to 11 for the “0” to “9” buttons. When one of the buttons is pressed, tc0.val holds its id. So, by first checking if it is between 2 and 11 (to prevent reacting on other touch press events) and then by subtracting 2, we get directly the number between 0 and 9 to compare with our random number and we can show and color the result accordingly. And all that in one single place:
tc0 Touch Press Event
if(tc0.val>1&&tc0.val<12) { sys0=tc0.val-2 // calculate the number from the pressed button id if(sys0==va0.val) { t0.pco=2016 // right, make it green }else { t0.pco=65535-2047 // wrong, make it red } t0.pw=0 // take the password asterisk away to unhide the number }
For the touch release event, it’s still much simpler, we just load page 0 to reinitialize everything:
tc0 Touch Release Event
page 0Now, we need still to initialize everything and to generate a random number between 0 and 9:
page0 PostInitialize Event
randset 0,9 va0.val=rand covx va0.val,t0.txt,1,0
16 lines of code in total, and that’s it.
Now, you may download the and play with the ready-to-use HMI file here: blog200418
Happy Nextion-ing!
