TextMesh Pro TMP_InputField - wrong behaviour within LayoutGroups

Hi,
it seems TMP_InputField forces a certain size to nested content, and this behaviour is not even overridable by a LayoutElements.

Two examples with slightly different setups.
A label is nested with an inputfield inside a container (Horizontal layout group).
in the second entry, the TMP_InputField component is moved to the container object, in the first its on the actual inputfield object.
Both result in undesired behaviour.
The first entry doesn't respect layoutgroups and LayoutElements.
The second breaks the label.
Repro project attached.
Any workarounds?

 

The hierarchy structure of the Input Field has to be maintained. As such, the 2nd example will not behave correctly.

The first example however should behave correctly but I am not certain what issue you are seeing in that one?

 

It's what i wrote in the first sentence that got a little pushed away by the picture.
If you check the hierarchy of 'FloatInput' in the sample and compare the 'Label' and 'InputField (TMP)' rect sizes, the label takes as much space as it needs, but the inputfield has this inexplicable forced additionaly margin. The nested text elements (Text Area/Placeholder & Text) inside don't take that much space, so it seems to be this component that forces it, and that's undesired.

 

The same applies to TMP_Dropdown

 

The following setup appear to work correctly on my end.



How does this behave for you?

 

the difference seems to be Child Force Expand as i see it. Unfortunately that does not change anything in the sample that i attached. It only forces children to expand, but does not loosen the restriction of the forced additional margin that prevents the dropdown from fitting (shrinking) to the preferred/desired size (the label works fine with or without child force expand)

 

TMP_InputField:4061 preferredHeight returns m_TextComponent.preferredHeight +16;
So this is actually a forced additional margin as suspected.
If i remove the +16 it behaves as intended.
Does it have to be there?

 

It looks like you are not using the latest release of the TMP package as this implementation was revised to use the actual offset values from the text area viewport instead of hard coded value.

The latest release is version 1.5.0 for Unity 2018.4, version 2.1.0 for Unity 2019.x and version 3.0.0 for Unity 2020.x.

 

Okay, It didn't show as update (from 2.0.1), probably because it isn't listed as verified.
But, yes, this update indeed fixes it. Thanks!

As a side note, the second example (floatInput_alt) in the attached sample has their elements jump around wildly, never ending, after this update in the editor. But i guess this can be ignored now as the component expects a certain hierarchy as you mentioned and the normal setup is now working as expected.