2025-10-26 9:35 PM
I have been trying to update a wild caard text area.
updateTarget will be called externally, value passed in will be 0-100
I started calling the function with 0 -> 10 -> 20...etc incrementally.
However whenever I passed the 100, the value will fallback to 0 and start again.
This is the where the problem occurs
Once I reached 100, and then the 0 will be displayed properly, but for later values there will be a "0" in the third character, even though I have checked the buffer is set properly.
The pattern is
0 -> 10 -> 20 -> 30 ... -> 100 -> 0 -> 100 -> 20 -> 300 -> 40 -> 500...etc
Below is an exaple of the buffer being set to "30" in ascii
But the display is
If I didnt trigger any screen update, after some time I can see there is a frame rendered (around per ~30s)
And the the display is back to normal again
It seems to be there is some kind of cache?
Anyone has a similar issue?
I am using the STM32U5G9J-DK2
TouchGFX: 4.26
Solved! Go to Solution.
2025-10-27 2:51 PM
Hello @BennyTang ,
Maybe I'm wrong but I guess you're using double buffer for your framebuffer strategy. The second buffer has the extra "0" added when you reached 100; and when you make the resize, you "forget" the extra part cause the length of your Textarea has reduced.
To avoid this issue, you can invalidate twice, as suggested by @JTP1 .
2025-10-27 3:07 AM
Hello
Try to add another target.invalidate(); also before printing new value to buffer with snprintf.
Hope this helps.
Br JTP
2025-10-27 2:51 PM
Hello @BennyTang ,
Maybe I'm wrong but I guess you're using double buffer for your framebuffer strategy. The second buffer has the extra "0" added when you reached 100; and when you make the resize, you "forget" the extra part cause the length of your Textarea has reduced.
To avoid this issue, you can invalidate twice, as suggested by @JTP1 .
2025-10-31 3:43 AM
Hi all,
I have tested by adding invalidate before writing to buffer and it works.
Just one more thing, I thought the "invalidate" is the "signal to render this object later" instead of "render it now"
Am I mistaken? If its just a "signal to render later" how does this fix it?
Thanks
2025-10-31 4:01 AM - edited 2025-10-31 4:01 AM
@BennyTang wrote:Hi all,
I have tested by adding invalidate before writing to buffer and it works.
Just one more thing, I thought the "invalidate" is the "signal to render this object later" instead of "render it now"
Am I mistaken? If its just a "signal to render later" how does this fix it?
Thanks
invalidate() says that area need to be rendered (again). If the new area to be rendered is smaller than the old area the older part won't get re-rendered unless it was invalidated. And therefore it stays there. When the render engine starts rendering it will simply only check the invalidated areas to render. I'm sure it has some type of optimization that it won't render the same area twice and if an area contains "nothing" it will simply erase it.
Also pay attention to the difference between resizeToCurrentText() and resizeToCurrentTextWithAlignment().
A similar thing happens when moving an object. If you change the location of an object you need to call invalidate() before and after the change. Or you use the build-in move() function that does it for you.
2025-11-02 6:18 PM
Thanks for the detailed answer!
I have tried changing the text area to a fixed size (instead of auto size) to fit in 3 digit.
And then use invalidate() (instead of invalidateContent()), and also delete the resize to resizeToCurrentText()
As a whole this force the whole widget to render the whole area instead of the "changed content", thus also fixed ther issue, while sacrficing the rendering effeciency (unchanged blank area rendered since invalidate() is used.
Anyway, this solves my issue and I understand clearly why it won't work in the first place.
Thanks again!