Start a new topic

Index program failure


for my private technical projekt, I had programmed a surface for my touchscreen.
In this development I saved my file a lot of times. 

After I reopened the "NEXTION EDITOR" with my file. Now, the Nextion Editor shows me the attached error-message.

Do you have any tipps for me, to work on my file without this error message? How can I adjust the index of my file?
I worked a lot on this file and I will not lose anything of it.

Thank you in advance!

Best regards

I was able to finally look at the header of the HMI
33 pages
1419 components
and 182913 code and attribute lines

There is a limitation currently of 65534 code and attribute lines per HMI project.
- this surely would have pushed it over the top, and when added in between compiles, you would not have been informed when it was just over, but so much over it may have been trying to over write itself looping around.  The compile process to build the TFT would have certainly informed of the limit.

I would not even be able to recover the HMI as it was truncated mid component, and did not yet get to the portion where the define tables are located close to the end of the file.  So with such information now lost, it can not be rebuilt from no data.

Going forward, there is at most 250 components per page,
 - but the 65534 code and attribute lines means you will need a coding technique or two to shorten this.

I did catch a bit in code you were using multiple vis commands:
when you have 20 pictures having vis being toggled and you can align the component ids to be sequential using the
Arrow Up/Down on upper toolbar of the Nextion Editor for Bring Top (Nth component) and Bring Bottom (1st component)
then it is possible to cycle through with something like:
   vis sys0,1

When you have the same vis being called several times from various locations and conditions
but it is toggling the same group of objects then
placing this into a hotspot resized to a 5x5 size and place out of the way
click m0,1
will trigger the code in hotspot m0 Pressed Event to be run

These types of things will help shorten your code segments to fit within the 65534 line restriction.
This 65534 is also shared with components, so there are nearly 62 attributes to a component
- some of these will take two lines, and 1419 components will chew many of the resources.

I would prefer that this is opened into a Free Chat topic in the forum, and we discuss in an
area where the general user base now and future can benefit from what will be learned.

Patrick Martin

(131 KB)
1 Comment

So now in the Forum

There is only one native array available, it was discovered by user indev2 random typings.

the b[.id].attribute component array allows access by .id number for component in a page.

b[0] in theory would be the current page as the Page Component is always .id of 0

b[1] would be the first component on the page with .id attribute 1

the last component has an .id attribute equal to component count

So in this b[.id] Component Array all attributes are accessible.  And this is good and bad.

For a Number component n0 with id 5 then b[5].val is equivalent to n0.val

  - but b[5].txt is also not a compile error even though n0 does not have a .txt attribute

     it will however, create a runtime error and program logic fails.

page4.b[3].val is the third component on page name page4 - great for accessing globals.

- but you really need to know that what you are calling is an attribute that truly exists

therefore if I have global string variable components in id positions 1 to 12,

  then I can use it very naturally for month names


If id 13 to 20 also were global string variable components containing weekday names

   then t1.txt=page0.b[rtc6+13].txt // rtc6 value+an offset

The weekday names is 13 to 20 as Sunday needs to be both 13 and 20 depending if RTC6 is 0 or 7

So this b[.id].attribute native array allows things to shorten a fair amount

   IF you take the time to specifically and purposely arrange your components

Login or Signup to post a comment