The caret is always missing in our InputFields since the update to Unity 5.2. The caret object is still created by the InputField and contains the usual Canvas Renderer and Layout Element components, but it simply doesn’t show up.
We can write text just fine, and even select portions, but we cannot see them or where we are writing. If we create a default Input Field from UI > Input Field, it has the same problem.
Adding an Image component to the caret in Play mode (we tested that manually through the inspector) makes it show up and work as normal. When it shows it still fills the whole text field, but then resizes to normal after we select the field.
We assume this is a bug with this release. What can we do? What has changed in order to cause this? The release notes couldn’t give us a clue (maybe something to do with UI rendering?).
This is dirty but works. The issue is before we would use a white texture if null was specified. This was removed so we now need to specify it to be a white texture (as done here). We are sad it was missed until earlier this week.
using UnityEngine;
using System.Collections;
using UnityEngine.UI;
using UnityEngine.EventSystems;
public class SetInputFieldTexture : UIBehaviour{
public InputField inputField = null;
IEnumerator Start ()
{
// wait a frame such that the caret GO gets created.
yield return null;
if (inputField == null)
inputField = GetComponent<InputField>();
if (inputField != null)
{
// Find the child by name. This usually isnt good but is the easiest way for the time being.
Transform caretGO = inputField.transform.FindChild(inputField.transform.name + " Input Caret");
caretGO.GetComponent<CanvasRenderer>().SetMaterial(Graphic.defaultGraphicMaterial, Texture2D.whiteTexture);
}
}
}
Thanks for the fix. In the meantime I had created something very similar that also waits one frame and them adds an Image component to the caret (I guess the caret gets the texture from the Image in that case). It also works (as a “dirty hack”).
yea i think my way might be better as the image will also want to control the verts of the caret where as the InputField is the one that needs sole control. Not saying your way doesnt work (as obviously it does) but there might be edge cases if the image tries to update the verts itself.
Any eta on when this patch will appear, or a more robust way of handling the issue than a yielding Start() method? We have lots of inputFields that are procedurally created at run time, which means they don’t exist when the containing behavior’s Start() method is called. We also have manually placed inputFields that are disabled at start, which means their caret objects don’t get created on the first frame of the parent behavior’s existence. I tried dropping your test-and-set-the-material code into the Update method of the behavior responsible for the inputFields in hopes of working around these creation timing issues but the inputField appeared to ignore the material changes.
Did you mean 5.2.0p1, that was released last week or actually 5.2.1p1, which will be released sometime in the future? I couldn’t find anything regarding the input caret in the patch notes…
I just installed p4, I am still seeing the issue though.
I get inconsistent results where I’ll have multiple fields that are configured exactly the same. Some will work and others will not. I will have to delete them and re-create them and sometimes they will work again.
Also, if I create a Prefab out of my form with Input Fields and then instantiate at some point while running, the caret does not work at all. Is anyone still having this issue?
