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.
I tried to "pic -x" or "pic >screenwidth" and nothing bad happens. So this can be driven exactly same.
Of course touch can't work offscreen :)
Creating new type of element is backward compatible, and prevent from sram consumption. New type could be like text/button with in-run editable position and text (and visiblity).
It is not a mere 4 bytes. Without coding logic it is 12 per component.
Such coding logic to have such reduced to 4 bytes will most likely exceed MCU flash
Right now such coding logic is not needed, it was prevented in Editor Build process.
I mean 4 bytes more than now :)
so that is already 12 bytes per component - not one component, all. Whole column of table.
.pw attribute was more simple, column only used by Text Component
.key attribute - only used by Text, Number and Scrolling Text.
.x, .y -> Every component (Including Variable and Timer to save space of coding logic)
Easy test is this.
When we as users can show it working in an RBT6 with all Nextion Functions still in tact.
Then maybe they have an alternative to consider.
Until then their brain power will make their attempts.
Im also thinking about xcen and ycen for example. It's wasting space.
Correct me, but we talk about 4 bytes per one movable element. Or 4 bytes in flash to store x/y is static/dynamic and 4 bytes in sram IF element is movable.
It isnt that much.
Yes, it does boil down to money - budget allotted to components.
For example, I imagine what processing Nextion could do if it used my Edison for its MCU.
And what kind of awesomeness you could add to your cam-on-rails with an Edison.
But on the STM/GD MCUs, a read-write attribute column, means sram on all.
This is why I complained about the .pw attribute already user capable
- as it stripped sram and attribute resources on every text component
(even though only one, or max two text components would ever use .pw)
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.
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
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
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.
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
Why you asking?
How this change anything?
What you see above is done only in nextion.
What MCU are you programming for your camera project?
How much sram and flash does it have?