About that textArea wildcard..

[HP]

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 · Accepted solution]

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]

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]

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

[Martin KJELDSEN]

In actuality, you may not even be seeing 155, but something like the following scenario depending on your typography, etc. You could say that, by keeping the size constant, you're always invalidating for worst case, which is ineffecient. I think we should probably look at adding a new method that can invalidate the area covered by the previous text to ensure that the framebuffer gets updated correctly.

[HP]

Again, thanks a million! It does make sense - I can see why it is more efficient to only invalidate the section you're actually updating.

Having a method that looks at what was previously there and clearing that area would be the ideal solution!

[Martin KJELDSEN]

No problem! And, right, it's a bit too much work for the user to figure this out. I get this particular question more than i'd like to admit.

Another fun one: If you're using the designer to create a wildcard text it will have "resizeToCurrentText" ticked by default. So, if the textarea has no initial value and the user never calls resize..() again, well, you can imagine =)

/Martin