Issue shown in video. Basically, my text mesh pro input field is moving from where it starts after I type something. How can I force the text to stay in place relative to its starting position? I’ve tried anchoring the position and justifying the editing text object left, right, and center but nothing seemed to work.
Any ideas?
Edit: will try this weekend, shaded. I am working on a gamejam game at the moment and want to wrap up that.
Are you able to change your anchor preset from stretch to right, and the change your pivot from 0.5, 0.5 centre to 1, 0.5 as well
Experimenting with the anchor was the solution. Thanks for the tip. ![]()
Hello, guys. I’m experiencing exactly the same issue with TMP InputField in Unity 6. Could you please share at which level in the hearachy you were able to fix it with adjusted RectTransform values? I tend to specify absolute sizes higher up the hierarchy and everything else (including the InputField, its Viewport / TextArea, and subsequently Placeholder/Text) is just stretched to the parent. However, I get the same problem as yourselves: the Caret stays in place and the Text is re-positioned to somehow compensate for the Caret movement. Should I play with RectTransform at the TextArea/Viewport level? Thank you very much
The two gameobjects I didn’t take screenshots of are | placeholders that I manually added to keep the appearance the way I wanted. Their anchor is 1, 0.5 as well.
Thank you so much for these. After having spent some hours on trying all possible RectTransform values I arrived at a different conclusion. My world space UI was designed in meters / Unity units and not scaled. Which means I was mostly working in fractions of 1. This is unconventional and one must design in tens/hundreds/thousands and scale down at canvas root accordingly. What seems to have happened is that some TMP code assumes pixels and works with integers, not floats. Which means that in my setup unintentional rounding errors and sticky values were happening. After turning my 1.6x.8 at scale 1 setup to 1600x800 at scale .001 the problem disappeared. It’s a bad design to be forced into specific numeric resolution if you ask me. Of course even float will ultimately have precision/granularity limits, but this is not that situation. This is a vaguely documented assumption by Unity engineers. Hope this helps someone with the same problem.



