TextArea won't invalidate properly (Shows old text as well as new).

[iw2lsi]

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

[Martin KJELDSEN]

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

[iw2lsi]

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

[Martin KJELDSEN]

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?

[iw2lsi]

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:

[Martin KJELDSEN]

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.

[iw2lsi]

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

[iw2lsi]

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

[Martin KJELDSEN]

Please do share your project.

Thanks!

[iw2lsi]

Hi Martin...

you are right! by removing the 1st iteraction everything works as expected.

thanks for your great support!

Giampaolo

[Martin KJELDSEN]

No problem! You probably forgot that you wanted to fade the image - I've just talked with the team and we may add a default background color to any new application or disallow the element just on top of the framebuffer to be faded.

Another note: In your code you had set the wildcard on textArea1 again in your concrete view. That's unnecessary since it's already done by the generated base view. You only want to set the wildcard buffer again in case you want to switch from the default one.

[iw2lsi]

fixed!

thanks again,

Giampaolo

[Martin KJELDSEN]

No problem! Thanks for reporting it - It rekindled the discussion about allowing users to fade certain elements :)