Font-clipping when updating string dynamically

Question

Hello!

I am running into a problem when updating a Text string via a device property. The updated string is clipped, only able to fully display one row. The original message the is displayed is "Welcome", and any change to the mentioned device string property will override this message with the new string. Changing the message to "Welcome to \njqpy" removes the lower parts of the letters on the second row.

The original text bounds is the size of the whole screen. I've tried to fix this by adding padding of empty rows over and under, both the original string and the updated one. I've tried to activate and deactivate auto size for the text view.

Do you have any idea why the text gets clipped and how to solve it?

Thanks

Answer 1

Hello Måns,

the '\n' sign forces the line break. Your approach should work. Why it is not working is difficult to deduce based on the provided information. For test purpose, have you tried to assign the string "Welcome to \njqpy" directly to String property of the Text view?

Do you have any idea why the text gets clipped and how to solve it?

Maybe providing a screenshot could help us to understand what exact effect do you observe?

Best regards

Paul Banach

Comments

Certainly! The left image is a screen shot from the prototyper where I've changed the default value of the device property to the message. The right image is how it appears on the device, but with different colors (sorry about the rotation). As you can see, the lower parts of the letters get clipped.

---

It means that the outputs are incorrect on the target system but in Prototyper everything is working well and the code running in the target system is generated from the same Embedded Wizard project?

If this is the case I would suppose an issue in the screen update. To narrow down the problem let me ask following information:

Which target system are you using?

Are you working with a target system using an external True Type font engine?

Have you made any adaptations/modifications in the provided Build Environment or generated code?

---

I've been able to resolve this issue by resetting the bounds of the text-box to cover the entire screen as the string has been dynamically updated. However, I still find this an unwanted behavior from EW.

To answer your questions:
Target system is STM32F769
No external font engine
Plenty of adaptations to build environment, but nothing that in my mind should affect font rendering. No changes to the auto-generated code.

---

Hello Måns,

it is still unclear for me what exact problem did you observe. Could you please provide us more details concerning the issue and how to reproduce it?

In your last comment you mention 'resetting the bounds of the text-box'. What was the original value of Bounds?

Best regards

Paul

---

This issue is not a priority for me anymore since I've found a work around, but I will try to assist.

I have a text-view that covers the entire screen (320x320). I also have a device string property that can be changed by the user. When initiating the text, I either set the string to the device property, or a multi-lingual constant string if the property is empty. The constant string is "Welcome" in a few different languages, and the device property is meant to be used to be able to say "Welcome to [your place]".

The problem occurs when the device property string is used. It seems as if the bounds of the text-view has been shrunk to fit the constant string, clipping long device property strings. All this occurs even though the bound is set to cover the entire screen. It is however solved by resetting the bounds to cover the entire screen after updating the string.

---

Using workarounds without understanding the problem is not really recommended. Since we have never seen a similar behavior, we suppose there is some peculiarity in your project. But which?

From your description I have understood, that the bounds of the Text view changed. Have you eventually configured the Text view with its property AutoSize = true? This is the unique possibility for the view to modify its own size by itself.

Also possible, is the Text view configured with its property Layout to resize itself automatically when the size of the superior component changes? Concrete does Layout contain the options ResizeHorz and/or ResizeVert activated?

If none of the above cases is true, can you review the implementation of your component searching for code which eventually modifies the Bounds property of the Text view?

Concerning the device property, at first glance I don't see any dependency causing similar behavior. Anyway, please review the native code (C code) where the string is prepared and passed to the GUI application. Note the section Be careful when exchanging strings. Especially, the string passed to the GUI application has to be created by using one of the EwNewStringXXX() functions described in the mentioned section.

I hope it helps us to understand the cause of the issue.

---

After further investigation, the root has been identified. The issue was because a simple mix up and indeed on our end. Thank you for your guidance!