Start a new topic

Assign current object id to vaX.val

HI,  I would like to get the current object id to a variable.
va0.val=currentid 
That would be used to inform a called function, who has called it.

In the attached example I'm using a single avriable and a single timer to perform repetitions for every every key of a page.  

The key performs its action and then enables the timer.
In my case I (manually) assign the current id to va0.val  and enable the timer.
The timer event simply send a click va0.val,1

It is ver usefull, and works very nice, but  problem arises when you delete some component, and all the ids of the page change !!
HMI

Your function works.


With regards to the problems that arise when you delete components

- it would then be important to not delete the components.=)


Something that I would do is move the components you have currentid's for

and bring bottom (renumber to id of 1)  with the Down Arrow on the tool bar.

With your four "buttons" then as 1,2,3 and 4,  your ability to add and remove

additional components can be done, with less interference from add/deletes.


It would also be important to understand the nature of the Nextion is sequential processing and not really class based.  This understanding will help you when you expand your ideas as YOU will need to strategize to implement many of the fundamentals.  I should also point out that this has already been done: pass to a variable a unique number from the button press so timer will increment/decrement the counter.


Whether it is relabeled and marketed as current id, or action1, action2 ... is still the same.

But you are now starting to take advantage of Nextion side processing.



Hi Patrick, thanks for your hints,
My approach is to help in cases where 'sequential processing' is not the best way.
I arrised to this solution because I get out of timers when implementing repetion on a page with 8 set-points (needed 16 timers ! ).
Actually I only have to manually  assign component id 16 times.
All the Nextion process is based on componet id  so a way to assign this id to a variable would be of a great help in many situations.
Can it be added to the 'whish list' ?
Regards

 

Intriguing.


So the click command or timer is kind of a branch, jump or goto of sorts.  But these are still being run through an interpreter sequentially.  I believe the only actual interrupt may be touch screen. And interpreted "made up functions, will most of the time take longer than the normal flow.


It is not worth wish list, to bloat the firmware will mean no room for other functions and really in the embedded world, few interrupts actually are used - it keeps you being able to follow and trace what is going on.  An MCU isn't really that sophisticated - not like the desktop systems.


BTW you may be interested to not the b[.id].attribute Component array this when used inside for statements can cut code lines, even if it isn't cutting down on real time.

Thanks Patrick,  
I thought that I had tried all possibilities, but had not tested (component-name).id
So  va0.val=t0.id   is the solution to my requirements, as it permits changes to a component id # without afect the execution.

 

When I read these posts another question came up: is it possible to address an object's attributes by id? So if I had the id of n0 in a variable, say "var0.val=n0.id", would it be possible to somehow set the n0.val to some other value via var0.val?

 

The attributes have to be of the same data type.  Somethings will simply not build

n0.val=t0.txt crosses such boundaries.  But numbers can be assigned to numbers, txt to txt.


In the time it took to ask the question and wait for a reply, you would have or should have been able to type 12 examples and pressed compile to see which pass and which failed.

Sorry, I seem not to have made clear enough what I attempted: I know that assignments between variables, numeric fields etc. are possible in various ways; I am utilizing that a lot in my code.

What I am really interested in is, if it is possible to _indirectly_ address a numeric field, text field etc, just by its ID. Like you would do in C with pointers or indexes to vectors. Phantasizing it could look like

var0.val = n0.id
OBJECT[var0.val].val=4711
var0.val = n5.id
OBJECT[var0.val].val=815
 
After this code sequence n0.val would be 4711, n5.val would be 815.

Did this make it clearer?

Without phantasizing C style objects, let me describe what is available.


The Nextion is NOT object oriented.  Hmm.  It is however, a record structure.

So there exists in the internal Component look-up table one entry per Component.

The current page Page Component is always .id of 0

 - the rest are sequentially numbered, and you can adjust this with BringTop/BringBottom


Now, Steve (username indev2) discovered that this lookup table can be accessed.

Using the b[.id].attribute Component Array.


There are approximately 62 attributes between all the components, each with a column.

If the attribute is legit, such as a .txt attribute in a Text Component -- success

- if it doesn't exist, the table has a -1 value and your HMI melts down on runtime.


So I can iterate through 10 components of the like type using a for statement

where these 10 components are starting at 23 through 32 ...

for(sys0=0;sys0<10;sys0++)

{

   b[sys0+23].bco=0

}


In the Nextion Editor when you select a component, the attribute pane will give a list

of key/value of the legit attributes for a component.

The ones in gray are enumerated

The ones in black are readonly at runtime

The ones in green are settable during runtime

and the ones in bold green are settable AND trigger a refresh.


An attribute you see in the Nextion Editor attribute pane has a column

the .objname is an exception, can't seem to find a means to access.


But, the clincher is, pair two incorrectly at runtime, and you HMI melts

- so you need to ensure you are exacting when you use this array.

"There are approximately 62 attributes between all the components, each with a column.

If the attribute is legit, such as a .txt attribute in a Text Component -- success

- if it doesn't exist, the table has a -1 value and your HMI melts down on runtime."


This seems to imply that a good bit is known about this table. Can someone share this knowledge? Is the "type" of an attribute (number, text, enumerated, etc.) accessible to program code? Are the columns accessible other than by name ("type", "bco", "x", "y", etc.)?



Ahhhhhh  Hey Lance,


Maybe about 8 months ago I started working with the Nextion and TJC Displays

My knowledge is from research, and lots and lots of it.


Although my knowledge of is such is I am almost able to build the TFT by hand,

It gets a bit more complicated in that Nextion is Closed Source

And since I now work with Itead in a consulting manner, the line of what I can disclose

becomes fuzzy at best.  Though I am not privy to the source, I feel conflict may exists.


My point I was making with what you quoted, the HMI is not object oriented

and object oriented programmers have different expectations of Nextion capabilities

But accepting it is a record based different expectations inline with firmware capabilities


Patrick,


I wouldn't wish for you to compromise your relationship with itead.


However, if anyone else who is not associated with itead can shed light on this subject, it would be appreciated.


It is not my intention to get into anything which is closed source. It has been said that information relating to the attributes table (and the b[?] notation) was published in a tutorial, so it shouldn't be something which itead did not want disclosed.


Most helpful would be a way to access the table columns by index instead of with b[n].attribute, information about which column goes with which attribute, and how the +-1" value indicating that an attribute doesn't exist for the object (component) appears. 


(I'm not at all sure that I have my terminology straight.)


As mentioned in another thread, I'd like to use this information to output a JSON file of the structure/layout of a page from a button or other code container on a page.


(Note that I know almost nothing about object oriented programming, so that's not what I'm talking about in any formal sense.)



Timing ... the itead logo vs the P avatar in my posts

So Steve discovered the b array before such covenants

Such was already user discovered and exploited for use.


So post-covenant tutorials had no issue, many projects then used it.

I posted the Yet-to-be-Documented b[ ] component array.


So a user could create and self-derive an attribute table

most component attributes are listed in the attribute pane.

I posted the component types based on this is exposed

But users should create their own table on their own


I will point out that Visuino software uses their data dragging

technique to work with the HMI file

So, although it is much work - it is possible.



Login or Signup to post a comment