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.
So perhaps users demonstrate how this can be accomplished in an RBT6 and retain Nextion capabilities and he has an option to consider.
Until then, his team will work towards if such a solution is viable.
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.
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