2019-02-01 08:42 AM
Hi...
I'm trying to update the contents of a textArea from a freeRTOS task but I have a problem on the second iteration... it seems that the new text is written on top of the old ones... even if I call the Invalidate() methods as reported below:
void Screen1View::setMessage(char* message, int msglen)
{
textArea1.invalidate();
Unicode::strncpy(textArea1Buffer, message, msglen);
textArea1.setWildcard(textArea1Buffer);
textArea1.resizeToCurrentText();
textArea1.invalidate();
}
why is this happening ? shouldnt invalidate() do all the magics ?
thanks a lot,
Giampaolo
Solved! Go to Solution.
2019-02-04 06:02 AM
Hi,
I found the problem. Try deleting interaction1 - It fades image1 (background) to 0 alpha, so essentially you have no background when you try to render text on top. The background image isn't updated properly on the canvas by the interaction because the framebuffer is immediately beneath it (there is nothing to blend with) - so that might have confused you. Once you've done that, you will now see the problem with "resizeToCurrentText" that we discussed previously.
But essentially you're using texts with wildcards in the right way (except for your resizing issue)
2019-02-02 05:11 AM
Hi @iw2lsi,
First, allow me to rewrite your code to clarify a few points:
void Screen1View::setupScreen()
{
textArea1.setWildcard(textArea1Buffer); //Just needs to be done once, if you're using the same buffer for the text area
}
void Screen1View::setMessage(char* message, int msglen)
{
Unicode::strncpy(textArea1Buffer, message, msglen);
textArea1.resizeToCurrentText();
textArea1.invalidate(); //You just invalidate once, when you're done with your operations like updating the buffer, resizing to current text. Any prior calls to invalidate() will have no effect.
}
The reason you're seeing old text as well is because your new text is shorter and now you're (most likely) seeing the tail of the old text. In this case you're not invalidating the "tail", if you get my meaning, because you resized the text area and you're telling TouchGFX to only invalidate the new, smaller rect.
Sometimes you need to avoid resizing to current text if a text is dynamically updating and has variable length. Here you should probably have a fixed width (Worst case) with an alignment that you're happy with (left or right). In this case you may end up redrawing parts of the screen that have not been updated, but you could do something clever with checking the length of the previous text and making sure you're invalidating as little as possible if this is a performance problem for you. Most likely it isn't.
Does that make sense?
Best regards,
Martin
2019-02-04 12:27 AM
Hi Martin,
thanks for your reply.
Unfortunately, it doesn't seems a size-related problem... as it affect the whole text and not only it's tail...
Attached you can see a screenshot of the screen... the two texts are "1234567890" and "ABCDEFGHIJ" and they overlap as if the 2nd one was just printed on top of the 1st one.
BTW: In TouchGFX "auto size" is not checked (but I've try w/ and w/o).
Best Regards,
Giampaolo
2019-02-04 12:30 AM
That's extremely peculiar. A call to invalidate() will force the rect that covers the textarea to be updated based on the contents of the TypedText.
Can you try making the code changes i posted?
2019-02-04 12:36 AM
Hi Martin...
the screenshot is the result of this code:
#include <gui/screen1_screen/Screen1View.hpp>
Screen1View::Screen1View()
{
}
void Screen1View::setupScreen()
{
textArea1.setWildcard(textArea1Buffer); //Just needs to be done once, if you're using the same buffer for the text area
}
void Screen1View::tearDownScreen()
{
}
void Screen1View::setMessage(char* message, int msglen)
{
Unicode::strncpy(textArea1Buffer, message, msglen);
textArea1.resizeToCurrentText();
textArea1.invalidate();
}
2019-02-04 01:59 AM
Any changes in behavior of the application?
2019-02-04 02:01 AM
Hi Martin...
unfortunately not... the screenshot I've posted was already using your changes...
Best Regards,
Giampaolo
Il giorno lun 4 feb 2019 alle ore 10:59 ST Community ha scritto:
2019-02-04 02:39 AM
Is this a problem on both Simulator and Target? You'd get this kind of behavior too if you did not have a background behind the text area, but it seems like you do.
2019-02-04 02:55 AM
Hi Martin,
the simulator doesn't work at all because of some compilation error...
I think I should put my freeRTOS-related code into some
#ifndef SIMULATOR
#endif
statements...
Converting images
Compiling gui/src/screen1_screen/Screen1Presenter.cpp
Compiling gui/src/screen1_screen/Screen1View.cpp
Compiling gui/src/model/Model.cpp
Compiling generated/gui_generated/src/screen1_screen/Screen1ViewBase.cpp
Compiling generated/gui_generated/src/common/FrontendApplicationBase.cpp
Compiling generated/fonts/src/Font_verdana_40_4bpp.cpp
Compiling generated/fonts/src/Font_verdana_20_4bpp.cpp
Compiling generated/fonts/src/FontGetters.cpp
Compiling generated/fonts/src/Kerning_verdana_40_4bpp.cpp
Compiling generated/fonts/src/Table_verdana_10_4bpp.cpp
gui/src/model/Model.cpp:2:22: fatal error: cmsis_os.h: No such file or directory
#include "cmsis_os.h"
^
compilation terminated.
simulator/gcc/Makefile:220: recipe for target 'build/MINGW32_NT-6.2/gui/src/model/Model.o' failed
make[2]: *** [build/MINGW32_NT-6.2/gui/src/model/Model.o] Error 1
make[2]: *** Waiting for unfinished jobs....
simulator/gcc/Makefile:182: recipe for target 'generate_assets' failed
make[1]: *** [generate_assets] Error 2
simulator/gcc/Makefile:40: recipe for target 'all' failed
make: *** [all] Error 2
2019-02-04 03:39 AM
Hi martin,
I've fixed the code to be able to compile the simulator again... and I'm now using a button to simulate the upcoming message... The behaviour is exactly the same... the text background is not restored before printing the new text.
I can share the code (I'm just testing TouchGFX+CubeMX+Atollic right now) if you wish...
Giampaolo