About that textArea wildcard..

[HP_it]

Diving a bit deeper into the whole model/presener/view thing I think I got far enough to try and have a task update a counter on the screen.

I'm in the process of doing this but I'm confused about the 'wildcard buffer' in TouchGFX designer.

Following the text of https://touchgfx.zendesk.com/hc/en-us/articles/207015345-Using-texts-and-fonts under the 'Wildcard' section, this is shown:

 TextAreaWithOneWildcard txt;
 Unicode::UnicodeChar txtBuffer[10];

So basically this creates the text area AND the buffer.

If I use the Designer to do this - isn't this code generated for me somewhere?

more specifically in the screen1View.hpp (yes I created a new screen for my application)

Furthermore the manual page states that I should write this:

txt.setTypedText(TypedText(T_TEMPERATURE_READOUT));

txt.setXY(10, 20);

txt.setColor(Color::getColorFrom24BitRGB(0xFF, 0xFF, 0xFF))

txt.setWildcard(txtBuffer);

add(txt);

 txt.setTypedText(TypedText(T_TEMPERATURE_READOUT));
 txt.setXY(10, 20); 
 txt.setColor(Color::getColorFrom24BitRGB(0xFF, 0xFF, 0xFF))
 txt.setWildcard(txtBuffer);
 add(txt);

Where I think that the setWildcard function should 'connect' the buffer and the wildcard.

When I choose to create a buffer inside the designer where is it created? or more importantly - what is it called if I can just reference it?

[Martin KJELDSEN]

Hi @HP​,

Yes, the wildcard textarea and the buffer are created for you in the baseclass for your concrete view (Screen1ViewBase.cpp/hpp - which hold all the designer generated code). You can check the name there, but it's named after your textarea. The code to place the textarea and connect the buffer is already generated for you if you're using the designer.

So, in a nutshell:

1) Connect a '\0' terminated Unicode buffer to your textarea with wildcard.

2) Fill the buffer (you usually do this in the concrete view through custom application code) using e.g. Unicode::snprintf()

3) call txt.resizeToCurrentText() to recalculate the size of the textarea so that the entire text is rendered.

4) invalidate the text area to ensure the newly calculated area is rendered.

/Martin

[HP_it]

Thanks @Martin KJELDSEN​ !

This was exactly what I was looking for! fantastic!

Could you add textArea1.resizeToCurrentText(); to the manual pages? It's not there at the moment

Also the note that the wildcard buffer is created in the ViewBase.hpp. I'm sure it's all over the place but after reading your reply I got home and got it working within 5 minutes!

[Martin KJELDSEN]

That's awesome! Thanks for the heads up, i'll make a note of it.

/Martin

[HP_it]

I have another question in regard to the textArea with buffer and wildcard.

I have now a working example with (hold on): TouchGFX integrated ind CubeIDE, running with a second task that handles UART comms and a message queue that sends messages to the GUI. I'm pretty pleased with this!!

Though I have a problem - the serial data is requested once every second and I get a single byte back, incrementing with 1 every time I get it. when I reach 255 it rolls over to 0 and start again.

I'm showing the value on the display but after the first roll-over I see the a 'leftover' of the previous value.

so first I see '0'

next I see '155' (The 55 is the leftover part from 255 shown earlier).

then I see '2' (now It renders correctly)

then I see '355' (the same leftover as previous)

it alternates like this all the way up to 100 where all 3 digits are used for displaying my number. of course it starts over when I'm back at 0.

I'm curious to know if this is something to do with double buffering? or is it the textAreaBuffer that needs some clearing? I'm pretty confused at this point.

Is this a known issue or am I doing something very wrong?

My method for updating the screen in the Screen1View.cpp is:

void Screen1View::updateTxt(int newValue)
{
 Unicode::snprintf(textArea1Buffer, 5, "%d", newValue);
 textArea1.resizeToCurrentText();
 textArea1.invalidate();
}

[Martin KJELDSEN]

First off: *clap*, good job =)

You're seeing some roll-over because (Hold on) you're invalidating something that is shorter than the string "255". You've resized to the current text and invalidated just that area! So, you've invalidated the part that, roughly, that covers the 2 and it now holds 1, but the 55 were never invalidated because the textarea is now shorter. And so on for (2)55, (3)55, (4)55, etc.

My suggestion is to not resize to current text. Have a fixed width for worst case (=255) and keep that size. Set your alignment how you want it in the text sheet and settle for just invalidating. Crazy huh? Yeah, it's one of the things that are a bit hard to grasp and may not be very apparent.

/Martin