2024-09-13 03:06 AM
I have a text field that's left aligned and rotated by 270 degrees so that the first character is at the bottom.
If I change the language where the text is longer the first character shifts down.
This is not what I expect.
I expect that a text that is rotated is the same as the unrotated text, but rotated around the side of the alignment (and perhaps shifted).
The problem is that the anchor point of the text is at the top left regardless of rotation, which is the right of the text when it's not rotated. So the text is effectively right aligned. For 0 and 90 degree rotation the behavior is correct.
A similar effect occurs when the text is right aligned and the text is rotated by 0 degrees and the translation is longer. In that case the text extends to the right instead of the left, so it is effectively left aligned. I understand that choice. But for manually setting text using a printf function there is a TouchGFX method called resizeToCurrentTextWithAlignment() which does extend longer text to the left if it is right aligned (I use this for printing real-time numbers, which you want right aligned for obvious reasons). I expect a similar method is used when rotating text so the extension behaves exactly the same as unrotated text so it would be consistent.
It would make more sense to change the rotation point to the bottom left in case of rotation by 270 degrees and left alignment, so the rotation point is always at the first character.
In case of Auto-size unchecked the text will increase length at the top, but won't extend beyond the anchor point and is masked. So this behavior is almost what I want.
I have two workarounds:
1) in constructor of screen view:
auto height = textAreaSide.getHeight();
textAreaSide.setXY(0, 426-height); // 426 is y+height of original text
This works, but is tedious as it requires me to calculate and type this for every rotated text in every screen. I don't like boiler plate.
2)
Auto-size unchecked and top lengthened by hand so height is larger than the width of the unrotated text.
This is slightly less tedious.
I don't know what resize method is called internally by TouchGFX in case of language change. It would make more sense to me to change this to an equivalent of resizeToCurrentTextWithAlignment() or at least give the user the option to change it ( an extra checkbox below Auto-size with something like "allow resize beyond anchor point", or "set anchor point to alignment side"). This won't take much CPU time.
I don't know whether this is a bug or poorly documented feature, but it would certainly help people to give the tools to get the desired behavior without having to use a lot of boiler plate.
Solved! Go to Solution.
2024-09-16 02:52 AM
Hello @unsigned_char_array ,
What you call the anchor point is basically the x and y position of the TextArea, that is why the text cannot expand over it. For it to expand over it, it should be re positioned (this is what you do in the first solution), but it would make it very weird to do that in the resizeToCurrentTextWithAlignment() method because we would loose the original x and y coordinate.
The autoSize of the TextArea is useful for 2 things :
Therefore, I think that your second solution is the correct way to use the TextAreas once you are a bit more advanced.
I could tell the team about this annoying behavior, but I do not think we would take action on this because it can simply be solved by setting the size manually.
I am sorry, this is probably not what you were hopping to hear from us but I am sure you can understand our point of view. :smiling_face_with_smiling_eyes:
I hope this comment clears things up, if it does, I invite you to select it as "best answer".
Regards,
2024-09-16 02:52 AM
Hello @unsigned_char_array ,
What you call the anchor point is basically the x and y position of the TextArea, that is why the text cannot expand over it. For it to expand over it, it should be re positioned (this is what you do in the first solution), but it would make it very weird to do that in the resizeToCurrentTextWithAlignment() method because we would loose the original x and y coordinate.
The autoSize of the TextArea is useful for 2 things :
Therefore, I think that your second solution is the correct way to use the TextAreas once you are a bit more advanced.
I could tell the team about this annoying behavior, but I do not think we would take action on this because it can simply be solved by setting the size manually.
I am sorry, this is probably not what you were hopping to hear from us but I am sure you can understand our point of view. :smiling_face_with_smiling_eyes:
I hope this comment clears things up, if it does, I invite you to select it as "best answer".
Regards,