Start a new topic
Not Taken

Possible to move object

As is stated there, i can't move element via modifing "black parameter".

So my feature request is to make it possible :)

I do not want to create nice movement animation or so, but simple move one element to other place.

Even if reload of page is necessary after moving, it isn't that bad.

But of course if moving in loop would be possible, it would be nice :)

I know i can duplicate it and hide/show, but for more elements its get more complicated and unreadable in editor.



Sorry mav   This is simply impossible.


So here is the only way maybe possible. 

- Create an Arduino compiler for Nextion.

- Rebuild TFT file

- Upload rebuilt TFT to Nextion using NexUpload

  - (During upload, of course Nextion will show serial upload)

New TFT has moved object


Reason why HMI can work in such minimal space is Flash is read only (static not dynamic)

If such were all in SRAM, there would not be enough SRAM for both

 - The firmware that runs your HMI project

 - Your HMI project


So one of them will have to go to  do what you seek 

Okay, so make user-selectable option to set static/dynamic positions of elements and then user decide which object he want to move - and also "sacrifice" memory to achieve this. Or even better - not only option for elements but for each axis (so eg. x-static, y-dynamic) if it could save more space. 


We both want to make nextion better.

Sure we do.


So I am just giving up information I know about the Nextion

Every attribute of every component makes a lookup table in the TFT.


When you look at which attributes are writable at run-time(in memory)

these are sporatic.  But every component has an x,y.

In order to turn x,y on, the scenario I described above occurs because

the whole column of the table would need to go into sram.

Its not merely just one component, but cuts sram for all of them.


So perhaps create a "yes no" like local global - another column and then

it costs more time to see if the item is sram or memory, and this slows not

just for your one component - but has to be checked for all components.


So its not that people don't want Nextion better, we surely do

- but it becomes impossible.

What we all can agree on is after a firmware change

 - we all want our projects to still run.



it makes no real sense, to try to port things which are doable on PC to an embedded device. Sorry, but a Nextion HMI is not a PC with 2GB Ram and an additional GFX engine and lots of other nifty things ...


Every enhancement must be inside the possibilities of such an embedded device. And finally not to forget, the user also like to upload his own code ...


If a device wont fit your needs, you just must choose the next bigger one which fit, but it makes not a lot sense to bend the existing ...


Every system has its technical limits, and we can't break them ...

So i can change font or xcen in runtime, but can't move it. Strange for me.

Okay so maybe you can create new type of element. Simple text(button) without "green" xcen,ycen parameters, but movable?


simply speaking, not possible ...


if text with dynamic position is needed, just use the xstr command ...


But it isn't touchable. And after created can't be deleted (only reload page can)


In other place of my project im moving items by "pic" (attachment)

but still its more "normal" way to move arrow, than putting new image at all frames of move.

mp4

Mav


What MCU are you programming for your camera project? 

How much sram and flash does it have?

Why you asking?

How this change anything?


What you see above is done only in nextion.

sendxy=1 could send coordinate of touch press/release


0x66 0x01 0x04 0x01 0x04 0x01 0xFF 0xFF 0xFF - 260,260 pressed

this would be followed up by a paired release only of original coordinate

0x66 0x01 0x04 0x01 0x04 0x00 0xFF 0xFF 0xFF - 260,260 released



I was thinking about it. But then I must know what X,Y, width/height of all elements is. And more messages/functions to turn on catching xy coordinates and drive them.

Of course it is possible, but definitely more work against simply message like from other buttons from nextion :)


Really I don't thought that this could be that hard and noone need this before. 


I need this for move dropdown menu in different places. So of course i can duplicate elements and show only current menu that I need, but way more elegant way is one movable menu.

The reason why I asked about what MCU you are programming with is so you might be able to make a comparison.

The Basic model's STM32F030C8T6 only has 64K flash with 8K sram.

An Enhanced GD32F103RBT6 has 128K flash with 20K sram


The basic firmware for Nextion has to work across what is common - that means within that 64K and 4608 bytes of the sram as 3584 is needed for the users HMI project.  An enhanced model provides additional things in its additional space using up to 12K of sram to leave the 8192 bytes for the users HMI project.  For the enhanced models, what is added to firmware that chews up a lot is the configurable GPIOs, eeprom and RTC.


So consider your project, and the space requirements it uses

- make a comparison to all the Nextion delivers

- merely try to consider what it takes to accomplish your ask within the extremely limited space that remains.


PS: This has been asked before, it is being considered.

Some of the best efficient programmers are probably attempting to squeeze it in without breaking existing.

My guess is first few attempts are over budget and don't retain user project space, so try and try again.


It is easy to ask for the impossible when no considerations are made to what does it take to do it

Reason kicks in when you make considerations

Deeper understanding comes with more considerations

In a static lookup table dumped into spi flash

 - things such as your x, y, h, w (those in black)

 - there is no need to error check these

    - does x and width try to draw off screen or

    - does y and height try to draw off screen

   Why is this important?

    - graphic handling.

So what happens when you try to compare pixel data at a location that exceeds your data boundary?  If lucky you get data that isn't suppose to be there to compare against.  If unlucky, it wrapped and you risk bricking your device with a divide by zero error.  But how is this ill compare going to effect the screen driver when attempting to assign these bad values into the pixels?


And how much space does this additional error checking take? 

- the answer to this is question is NONE or WAY TOO MUCH.


Lots of this error checking is done by the Nextion Editor build process.

- To prevent bad values from getting into the compiled TFT.

   Wonder why you can't do modulus using a variable?

     - error check is editor side, no check Nextion side - space NONE

   Wonder why your X and Y is not dynamic

     - error check is editor side, no check Nextion side - space NONE

   Wonder why waveform needs an absolute integer in the add command

     - no checking Nextion side for component type, much smaller requirement if integer.


So where should all this error checking be?

  attempting to do it Nextion side within what remains of the 64K and 4604 bytes?

  or Editor side with massive amounts of RAM and plenty of space.


Wonder why there is no better graphics?

 - no space for Graphics Library

Wonder why no drawing off screen?

 - no sram to house pixel data for virtual screen space used

Wonder why no SD access during runtime?

 - space SD lib takes, means no space for user HMI

Wonder how SD is used during TFT upload process

 - firmware portion to run HMIs is not in memory


So just ponder about these things.

- after all, when we make our projects,

  we should understand from what we go through to program our MCUs

  is the same kind of thing they must go through to program the Nextion MCU

Thank for detailed explanation.

Currently nextion is faster than my MCU. I have enhanced version (NX4832K035_011R(With Touch)).

Still. If there is need for more calculations (good point btw), well...really that much?

Even atari or amiga has moving windows and still can work with it. And they working on much slower machines (but with more memory)

Still if moving elements is impossible in real time, i can wait few frames for calculations.


It isn't nobody fault, that "there is no space", and I know that everything is money.

Login or Signup to post a comment